5 ms·

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

rjmunro 4y ago
Not really, because they only see differences they have caused themselves, so they know about it.
- xcambar 4y ago
  And so they forget about it.
izietto 4y ago
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
diarrhea 4y ago
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.
- CorrectHorseBat 4y ago
  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.
  - diarrhea 4y ago
    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 https://jasonstitt.com/gitignore-whitelisting-patterns
  - nishs 4y ago
    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).
gvx 4y ago
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?
lozenge 4y ago
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.
dundarious 4y ago
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.
trey-jones 4y ago
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.
malingo 4y ago
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.
RHSeeger 4y ago
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.
- mirceal 4y ago
  Is this a problem though? I can see the upsides of ignoring the files in the shared gitignore. Are we trying to save space??
  - dahart 4y ago
    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.
    - mirceal 4y ago
      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.
      - dahart 4y ago
dahart 4y ago
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.
fishywang 4y ago
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).
- fomine3 4y ago
  Thanks for pro tip, git clean -ndx is my friend.

rjmunro 4y ago

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

xcambar 4y ago
And so they forget about it.

izietto 4y ago

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

diarrhea 4y ago

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.

CorrectHorseBat 4y ago
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.
- diarrhea 4y ago
  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 https://jasonstitt.com/gitignore-whitelisting-patterns
- nishs 4y ago
  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).

gvx 4y ago

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?

lozenge 4y ago

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.

dundarious 4y ago

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.

trey-jones 4y ago

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.

malingo 4y ago

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.

RHSeeger 4y ago

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.

mirceal 4y ago
Is this a problem though? I can see the upsides of ignoring the files in the shared gitignore. Are we trying to save space??
- dahart 4y ago
  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.
  - mirceal 4y ago
    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.
    - dahart 4y ago

dahart 4y ago

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.

fishywang 4y ago

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).

fomine3 4y ago
Thanks for pro tip, git clean -ndx is my friend.