Hacker News Reader

Comment by p1necone | Hacker News Reader

This seems like it could potentially be a source of confusion - different devs on the same project would see different ignore behavior.

View on HN

In many ways that’s a good thing. I don’t want to have ignore entries for 10 different text editors in every project’s .gitignore. Put that stuff in your personal .gitignore. In general, I don’t want commit history to contain any of these “just for me” changes even aside from .gitignore. Project .gitignore should mostly just ignore the stuff that your build/CI produces, which itself should hopefully be just a single `build` directory.

As far as I can see, this only comes into play when newly adding files to be tracked. If you created a 'source.file', but your global gitignore ignores all '.file' files, then you'd notice immediately. You wouldn't commit and push because you were unable to add the file in the first place.

If another developer has added a 'source.file' and you pulled it in, your global gitignore would not be triggered, since the file is already tracked in the repo.

It would also come into play of you add code that generates files which should be ignored, but you don't realize the gitignore has to be updated because it's ignored in your own global gitignore.

Very good observation. That's a reason I'm itching to try out an approach akin to this (in a future project): https://jasonstitt.com/gitignore-whitelisting-patterns

Excellent point!

Tangentially, to prevent scenarios where generated code becomes out of sync, in your CI you should always re-run generators and check that `git status` shows no entries (and fail the build if it does).

I am surprised this isn't expected. Sure, it's nice to have common build files ignored. But I have all kinds of files locally (editor files, etc) that are specific to me, not common to my team. I don't expect my team to have the same ignore list as me, nor would I want my ignore list cluttered with entries that only apply to them. I see it the same as an editor/IDE config; each person has their own, and putting them in version control tends to cause issues/noise.

Is this a problem though? I can see the upsides of ignoring the files in the shared gitignore. Are we trying to save space??

Yes it is a problem when a project involves more than a few people. If there are really common ignores that multiple people use, it’s fine to share those. But one-off folder & file ignores should not be dumped into the shared space. It has nothing to do with disk space, and everything to do with clean semantic project organization. Shared ignores should be primarily a declaration of temporary files & folders that the project produces during build/run/etc. - things that everyone will need. Adding personal folder ignores to the shared .gitignore can not only be confusing about what intermediate artifacts are expected, it can cause problems or conflicts for other people. A small dumb example is if someone tries to make a new shared folder and someone else already shared an ignore. I’ve seen it happen, and it’s not a big deal, but caused temporary confusion. You can cause issues with git history and pulls and bisects when there’s churn with the ignores.

Back on earth, a few lines in an ignore file would not make anyone blink. I guess you're a purist and everything about your software shines! Perfection.

> Back on earth, a few lines in an ignore file would not make anyone blink. I guess you're a purist and everything about your software shines! Perfection.

I didn’t downvote you, and I don’t understand your sarcasm toward me when I’m trying to explain the practical answer to the question you asked. This isn’t just a few lines on a large project, and it’s not even about the extra lines at all. The issue is that personal preferences don’t belong in a shared file, and their presence can cause real and actual problems in a large project, problems I’ve witnessed and experienced first hand. One single bad line in .gitignore can cause trouble for everyone on the team when they need to checkout different branches. If you have 50 or 100 people adding their own ignores, they can and do easily conflict with each other. The shared .gitignore just isn’t the spot to list your personal folders, which is why git designed other places for you to put those.

As long as you know your own ignore behaviour, I don't see how it can cause confusion... except maybe if you share the drive the repo is stored (either as a network drive or you share the physical drive via sneakernet) but why would you do that instead of cloning the repo?

This is by design, and not a problem in practice: ignores are declaring unshared files & folders. If ignores change the state or behavior of the project, it means someone didn’t use ignores correctly, didn’t think through what ignore behavior should be shared and what shouldn’t. Sometimes there are folders everyone will have that should be ignored, like a “build/“ folder, and sometimes there are folders you make yourself inside your repo and don’t want them checked in, like test scripts or output images or whatever. The personally ignored artifacts should be different ignore behavior.

Global gitignore should in general only be used for things that's "unique" in your local environment, like:

* IDE/Editor (for example, add `.vscode` to your global gitignore if you use VSCode, add `.idea` if you use IntelliJ family, NOT add `.editorconfig` because that's intended to be cross environment)

* OS level spam (`.DS_Store`, etc.)

* Any file generated by a tool you use locally

Also a pro tip, I have this alias in my global git config:

    why-ignore = check-ignore -v --no-index

So I can use `git why-ignore path/to/file` to show why a file is ignored (e.g. it shows which line in which gitignore file excluded it).

Thanks for pro tip, git clean -ndx is my friend.

Not really, because they only see differences they have caused themselves, so they know about it.

And so they forget about it.

I agree. The same problem (different devs with different settings) is solved by specifying line endings in per-repo .gitattributes files instead of global autocrlf settings. And we all know how much confusion that causes.

I wouldn't use this for system files, but I have the pattern "loz_*" and it lets me keep "my" odd scripts in the repo folder but permanently untracked.

This is the reality of the global .gitignore. Unless you have a full team of super competent and well rounded devs that think alike, one is going to come up with a strategy of "ok, everyone should obviously put stuff like .vscode in their global gitignore; it has no place in the local one" while somebody else doesn't care a bit, and it's really kind of a silly thing to try and enforce protocol around. Much bikeshedding detected.

It is as soon as you forget about that-but, speaking of myself, it is not because I'm aware of the fact that I'm using it

Reply on news.ycombinator.com