Re: Lack of system-level excludesFile

From: Jeff King <peff@peff.net>
Date: Oct 3, 2024, 21:24 UTC
Message-ID: <20241003212451.GA12763@coredump.intra.peff.net>
In-Reply-To: <CANp3UNB_4_mcK4CV3WF7p3AWaLTK6qb13tS3imDBGU5XBOzG0A@mail.gmail.com>

On Thu, Oct 03, 2024 at 01:45:07PM -0400, Sparr wrote:

Show 22 quoted lines

> On Thu, Oct 3, 2024 at 11:40 AM Junio C Hamano <gitster@pobox.com> 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. :)