11–20 of 72 posts
Easy enough to catch but you'll miss some. Literally no cost to adding it to repo config either
Disagree. Many projects may want to commit IDE files. Ignoring them globally is simply wrong.
oh wow, really! why? sounds like a horrible project, imagine those git conflicts 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?
Some focus on battles they are likely to win, others on battles they are bound to lose.
You'd still need a repository .gitignore, more-so if you're not working in a professional development shop (i.e., SMB/enterprise IT) or open source project. 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 fo…
> 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.
Earlier quoted context omitted.
yes we still need the repo git ignore for specific items for the repo it was more about stop using the repo git ignore for everything, rather than not use it at all
Yeah, people putting MacOS-specific files that have no relation to the codebase in the .gitignore should stop.
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.
Being honest, I dislike the tone of this sort of clickbaity rephrasing of the article title. The actual title is "You must use your Global Git Ignore!" which is completely true; the nuanced observation from the article "Using the git ignore feature is great but it has limitations, which is why I think this file is overused and often incorrectly" is a worthwhile hook, and presented thoughtfully. The title "Stop Using…
Yes the title is a little bit controversial
.git/info/exclude