"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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 ;-)
