On Thu, Oct 03, 2024 at 01:45:07PM -0400, Sparr wrote: > On Thu, Oct 3, 2024 at 11:40 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > If you take the reasoning one step further [*], it may make sense to > > have a list of ignored patterns that applies to everybody on the > > system, regardless of who they are, what editor they use, and what > > project they work on. > > > > Having said all that, wouldn't that be already supported? What > > prevents you to set core.excludesFile in /etc/gitconfig? > > I tried to cover this in my original email. You can set that and it > will apply to all users who haven't set up their own > core.excludesFile. But this has two problems. > > 1. It will disable the default behavior of a user being able to put > their own ignore rules in $XDG_CONFIG_HOME/git/ignore which I suspect > more than a few current git users rely on. > > 2. As soon as a user sets core.excludesFile in their account-level > config, to be able to create account-level ignore rules, such as based > on their desktop environment or editor or all the other stuff people > typically want to put in their excludesFile, they will lose the > functionality provided by the system level ignore file. Yeah, I agree that the current system is not quite flexible enough. And there is some prior art already in /etc/gitattributes, which we respect in addition to core.attributesFile. I did wonder briefly if we could let core.excludesFile be a multi-valued list (so you could add a user one on top of the system value). But that would break backwards compatibility for people who expect the current last-one-wins behavior. And also would interact weirdly with the XDG fallback, as you noted. So I think it is reasonable to add a system-level version of gitignore. I'm not sure how often it would be used, but it certainly fills a gap and would make it consistent with config and attributes files. You can grep for ETC_GITATTRIBUTES to see how the attributes version is configured and used. -Peff PS If you want to get really wild, consider this: the exclude/ignore feature is really just a proper subset of the attributes system that came later. If we were designing today, we could ditch .gitignore entirely in favor of a special "ignored" attribute, and then you could just use /etc/gitattributes to do what you want. I'm not sure if people would find that more syntactically awkward; it is nice that you can just dump files one per line into .gitignore without special syntax. But it's possible that we could provide _both_ mechanisms, and let the user do whichever they find easier. That's obviously a much bigger project than just adding an /etc/gitignore file, though. :)
