Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically ignore files in .gitignore #475

Closed
jdufresne opened this issue Aug 23, 2018 · 9 comments
Closed

Automatically ignore files in .gitignore #475

jdufresne opened this issue Aug 23, 2018 · 9 comments
Labels
T: enhancement New feature or request

Comments

@jdufresne
Copy link
Contributor

I think a feature to automatically ignore files and directories listed in .gitignore would be useful. This file normally contains a long list of auto-generated files or files that are otherwise unnecessary to format. By pruning these big directories, black will run much faster. By adding such a feature, black will require even less configuration as most projects will no longer require passing --exclude on the command line.

Other opinionated code format tools already do this or are discussing this. For example:

JavaScript Standard: https://standardjs.com/#how-do-i-ignore-files

Paths in a project's root .gitignore file are also automatically ignored.

PHP-CS-Fixer: PHP-CS-Fixer/PHP-CS-Fixer#3947 (comment)

I think it can be fixed in a broader, generalised way, by parsing (and excluding the results of) ignore files like .gitignore.

@zsol zsol added the T: enhancement New feature or request label Aug 24, 2018
@zsol
Copy link
Collaborator

zsol commented Aug 24, 2018

I think this is reasonable for black to do :)

@behnam
Copy link

behnam commented Sep 29, 2018

See also #541.

@jgirardet
Copy link
Contributor

I'll go for it.

@jgirardet
Copy link
Contributor

What should be the expected behavior between DEFAULT_EXCLUDES, command-line, pyproject and .gitignore ?
Should we just merge them or should the use of one ignore the others ?

Actually : command-line > pyproject > default. each is exclusive.

.gitignore being everywhere I don't know if we can be as exclusive.

My proposal when .igitignore exists:

  • a non empty .gitignore replaces default. I'm not sure for this one.
  • command line overrides all(pyproject, default, gitignore) : so it would stay as it is now.
  • .gitignore + pyproject should be merged ignoring default. some directory could be versionned without needing being blakened

thanks for your opinion on it.

@jgirardet
Copy link
Contributor

I need your opinion to go on @zsol

@Natim
Copy link

Natim commented Nov 30, 2018

This is the kind of errors I'd like to get rid of:

error: cannot format kinto/plugins/admin/node_modules/react-breadcrumbs/demo/node_modules/node-forge/tests/server.py: cannot use --safe with this file; failed to parse source file with Python 3.6's builtin AST. Re-run with --fast or stop using deprecated Python 2 syntax. AST error message: invalid syntax (<unknown>, line 74)
error: cannot format kinto/plugins/admin/node_modules/react-breadcrumbs/demo/node_modules/node-forge/tests/forge_ssl/forge/ssl.py: cannot use --safe with this file; failed to parse source file with Python 3.6's builtin AST. Re-run with --fast or stop using deprecated Python 2 syntax. AST error message: invalid syntax (<unknown>, line 125)

I have no intention of formatting a node_modules folder, also one could argue that this folder has nothing to do in my code tree, but apparently for some reason it does...

Note that --exclude "/node_modules/" will do for now

@zsol
Copy link
Collaborator

zsol commented Dec 4, 2018

Because we have --include, I think the most sensible option is to merge gitignore with the value of --exclude; if there's no --exclude, merge it with the default. Values in pyproject.toml basically replace the default value for command line options.

@xmo-odoo
Copy link

xmo-odoo commented Feb 6, 2019

FWIW, on top of automatically parsing .gitignore & .hgignore (and possibly some others) several code-searching tool have standardised on a .ignore file with similar semantics, so support for that would also be nice.

@ambv
Copy link
Collaborator

ambv commented Mar 3, 2020

This was solved with #878.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants