Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.gitignore Isn't the only way to ignore files in Git

nelson.cloud

Post reply on HN
Print view View original

101–110 of 188 posts

Re: .gitignore Isn't the only way to ignore files in Git

#101

Post by zarzavat »

kodablah wrote: post #55
Anon1096 wrote: post #37

Earlier quoted context omitted.

You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.

This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their sit…

I add .DS_Store to every repo despite also having it ignored globally. Efficiency beats pristine. I don't want to have to ever think about or deal with it at all.

Re: .gitignore Isn't the only way to ignore files in Git

#103

Post by gugagore »

hungryhobbit wrote: post #61

Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`. This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file…

People are jumping on it being an important file to review. You don't want to ignore the diff.

Even if that's true, you definitely do not want to attempt merge two lock files, and using the .gitattributes file to set the merge strategy is a good idea!

Re: .gitignore Isn't the only way to ignore files in Git

#104

Post by inigyou »

zarzavat wrote: post #101
kodablah wrote: post #55

Earlier quoted context omitted.

This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their sit…

I add .DS_Store to every repo despite also having it ignored globally. Efficiency beats pristine. I don't want to have to ever think about or deal with it at all.

but you do think about it when you add it to every repo?

Re: .gitignore Isn't the only way to ignore files in Git

#107

Post by panzi »

selcuka wrote: post #91
po1nt wrote: post #67

Earlier quoted context omitted.

It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.

> you just want to see that the file changed I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).

Python packages aren't quite so insane on transitive dependencies. The diff of package-lock.json can be novel length.

Re: .gitignore Isn't the only way to ignore files in Git

#108

Post by h4kunamata »

>~/.config/git/ignore

This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels.

I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.

Re: .gitignore Isn't the only way to ignore files in Git

#109

Post by atomicnumber3 »

h4kunamata wrote: post #108

>~/.config/git/ignore This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels. I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.

Idk, I can imagine a specific weird usecase. I use IntelliJ. My coworkers don't. They don't want my .idea folder in git. (You're probably thinking "ok, yep, gitignore!" And you're right except my boss ideologically does not want any *hint* of what IDE you use in the repo. Including in the gitignore.

So each person putting .vscode or .idea in their local config's ignore actually makes sense. (Relative to the nonsensical parent requirement... of course).

Re: .gitignore Isn't the only way to ignore files in Git

#110

Post by Groxx »

selcuka wrote: post #91
po1nt wrote: post #67

Earlier quoted context omitted.

It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.

> you just want to see that the file changed I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).

same - I check the changelog for every major (== minor if v0) and some minor version changes in most of my projects, including at work. I've caught quite a lot of would-have-broken-something changes, and opportunities for fixes/optimizations/etc by doing so. and sometimes they mention fixing a bug we didn't know we had, so we learned about it early before it corrupted too much data.
Post reply on HN