Re: Lack of system-level excludesFile

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> So basically, I think such a feature could be useful, but I also don't
> see it as immediately necessary because the global (per-user) file is
> also generally useful for this if the user is aware enough to know it
> exists (which I admit they might not be).

I was around ;-) and the reasoning is exactly that.  

Per-user setting was considered the most appropriate (not "good
enough", but "more appropriate than system-wide") primarily because
the exclude list generally is just as personal as it is personal
what editor is used.

The same reason led to the thinking that it is perfectly fine to
have "*~" in the list of per-user exclude patterns for an Emacs user
but it is dubious to have in the list of system-wide exclude
patterns, if such a thing existed, when the system is used also by a
vi user.  I do not think it was explicitly argued, but it is natural
to lead to the conclusion that it was not worth adding such a
mechanism.

And that led to recommendation that these patterns of personal
nature should be left out of in-tree .gitignore file.  The Makefile
and the project source would dictate what build artifacts are
expected to be created in the working tree of a checkout of a
project, and in-tree .gitignore is the perfect mechanism to mark
these *.o, *.a, and *.pyo files to be ignored, but because not
everybody who work on the project uses Emacs, so "*~" falls into a
different category from these "usual build artifacts" and the
recommendation was to leave these outside the in-tree (or the list
of system-wide patterns, if we had a mechanism to specify such a
thing) .gitignore files.

But this thinking and recommendation changed over time, and I think
people (including us old-timers) take a more relaxed stance these
days.

If the contributor base of the project includes both Emacs and vi
users (and in this day and age of DEI, you are encourged to be
"inclusive" and prepare for the folks from other camps to join the
project in the future, even if your contributor base is solely vi
users), it will not be likely that the project wants to have any
files that match "*~" to be tracked at all, so having such a pattern
in in-tree .gitignore file to be shared by all participants would
not hurt anybody.  Emacs users will be helped by not having to worry
about configuring their per-user configuration, and vi users won't
be hurt as they are not going to add a tracked file foo~ to the
project (and alienate their friends in the project who happen to use
Emacs).

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?

Thanks.


[Footnote]

 * This may be a larger step though, as the set of projects that a
   single user works on is much narrower than the set of projects
   that any users on the same system work on (hence the types of
   files that are potentially tracked by these projects are much
   wider for system-wide exclude list to take into consideration).

   On the other hand, are massively multi-user systems (like the
   time-shared system studends 30-years ago used at Universities)
   still a thing?  If not, then having a pattern that may hurt
   people with other preference on the system-wide list would not be
   a problem at all---after all, you have the entire system without
   anybody else.  But at that point, system-wide and per-user would
   become the same thing ;-)