Many projects may want to commit IDE files. Ignoring them globally is simply wrong.
can you elaborate on why they would want to commit IDE generated files? I have only seen this in legacy projects
what happens if people want to use different IDEs?
Not an issue
> why they would want to commit IDE generated files
You added the word generated.
Many Windows-oriented projects a Visual Studio .sln file. This is great! You can open the sln, build, and run. It “just works”. Very nice. I wish more projects did this.
> what happens if people want to use different IDEs?
That’s fine. Nothing stopping it.
IMHO the .gitignore should be the source of truth.
There don't seem to be any downsides to a long .gitignore. Who cares if it is 100 or 1000 lines?
Kind of pointless, in my view. I think a user-global .gitignore is fine to have to make sure you don't make mistakes for net-new projects or projects where someone forgot to add your exclusions, but otherwise, you're going to need both if you choose to use a user-global.
> The contents of the repo’s git ignore is for the project only files and folders. Developers can customise their own global git ignore with extra exclusions they need.
The two gitignores are for different purposes. The user-specific gitignore (~/.gitignore, or ~/.config/git/ignore) is tailored to the developer's specific workflow and preferred tools, so for example, a Vim user would have different rules from an Emacs or VSCode user.
The project-level gitignore(s) are for build products. For example, if the project's build scripts create a "build" directory for all the build products, "build/" would probably be in the project's .gitignore.
It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project.
Why not? What's the harm?
There seems to be zero significant downsides to include editor or operating system-specific patterns in the project .gitignore. A long .gitignore doesn't cause performance issues.
To wit, you'll ultimately have someone without a global .gitignore that will lead to PR cleanup (or worse, direct commits).
The project level .gitignore prevents mistakes by all committers. This is superior to trusting a developer correctly set up their own .gitignore.
I think this is getting to the level of "optimization" because it feels good rather than doing any true good.
it was more about stop using the repo git ignore for everything, rather than not use it at all
Use the repo’s ignore, not your own.
Yes we should use git ignore for the repo specific items, so if the repo has terraform it should ignore generated files - but not desktop tools people use as we all use different dev tools
> Yes I am saying this is wrong… (let me know if you agree/disagree below)
I didn't realize that the first paragraph is saying "This is good"; I thought the second paragraph was saying that the first paragraph is bad.
The title "Stop Using Git Ignore", which the author of the blog post chose for this submission, doesn't represent his actual article well, though it probably gets more upvotes on Hacker News. I wish he'd presented the article more accurately, as it's a worthwhile observation that, for example, we probably have so many .DS_Store files and .vscode/.idea directories that defining them once will save us some hassle.
Yes the title is a little bit controversial
> Everyone uses different operating systems, IDEs and dev tools.
How is this related to .gitignore?
> This list will only keep growing, it will never end
Where's the problem? A random Facebook's repo has its gitignore file weigh 2KB[0]. Is this a problem?
> Is the “.gitignore” file competing with the “README.md” for the most updated file in the git repo? I hope not
Again, why is this a bad thing?
The author just wanted to rant about something but didn't know about what
*[0] https://github.com/facebook/facebook-ios-sdk/blob/main/.giti...
Than you for reading the article and for sharing the FB link with a git ignore example - the contents of the example file is not long because it doesn't have every dev tool possible, so I think you proved my point - so thank you :)
Strong disagree. Please do continue trying to educate the community, but that's no reason to take the guardrails off.
From my experience the main downside of keeping the "guardrails on", people are less likely to learn about the importance of git global ignore and also with open source projects there can be a green square chasing game (which we also need to educate people on) - just thinking about this, more Pull Requests will come in with unwanted files though, which will be painful for contributors and maintainers, but could be a good lesson?
"...for your personal files"
for you and your tools, but what about everyone else?
Look at using dotfiles to sync your computer's config to multiple computers, it is a great tool
Easy enough to catch but you'll miss some. Literally no cost to adding it to repo config either
The first place to catch errant build files and artifacts from entering the repo database is the .gitignore file. The second place to catch them is the PR. The .gitignore prevents repetitive file adds from entering the PR.
What I don’t want to see in an enterprise environment is someone checking in a 100MB binary file that gets checked into dev because the team was busy and approved a PR hastily. What would be helpful is a git hook that checks the mime type of a file and decide if it should even by a type of file that should be checked into a project.
I will look into this idea. Thanks again
Almost mandatory for monorepos too!
I really appreciate you adding value to the conversation, thank you!
.git/info/excludeNot me, never heard of it.
I use ./.git/info/exclude to bypass commits and pushes, that is good enough for me.
Quickly reading the title, I though it was about stop using git period, go to something else :)
Some focus on battles they are likely to win, others on battles they are bound to lose.