Conversation
|
I quite agree with this. No project just needs a blanket .gitignore file like that one. |
|
It isn't really best practice for a blanket gitignore like this to be in every project. Blanket ignores should be git global config on a user by user basis for their common temp files and the like (e.g. one user has vim swap files globally ignored, another has emacs temp files globally ignored). Project gitignores should be for derivable files (and other files that should stay out of version control, like databases) common to the project. A project written in Python doesn't need .o files ignored, one in C doesn't need .pyc ignored, etc. Plus, if you're going to have the bot add a .gitignore, put it in the commit message. A commit that says "Removes whitespace" when it just adds a .gitignore is plain wrong. |
|
I also think the .gitignore feature should be gutted. It's not project specific which is inappropriate. I can't see a use case where accepting a pull request for that boilerplate .gitignore file would be useful. If the feature is not gutted it should probably at least submit a separate pull request for adding the .gitignore. A pull request for whitespace fixes would likely be rejected by many projects if that .gitignore file was also included. |
|
+1 |
|
❤️ |
|
+1 |
|
+1。 |
Adding a .gitignore is unnecessary and just annoying if the project did not actually remove any whitespace (ie, do something useful).