{"thread":{"id":"62245","subject":"Lack of system-level excludesFile","startedAt":"2024-10-03T00:23:31Z","lastAt":"2024-10-03T21:55:32Z","messageCount":6,"participants":["Sparr","brian m. carlson","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"504007","messageId":"CANp3UNCXqLJmAj2Vc7jB+i9qRjfKzrri_Mr9VvG4J5tUR-1HeQ@mail.gmail.com","threadId":"62245","inReplyTo":"CANp3UNBGd=jiSZyFSAdPjayvgHbP5SF4Dm-uCNwna_H16bRgRA@mail.gmail.com","subject":"Lack of system-level excludesFile","fromName":"Sparr","fromEmail":"sparr0@gmail.com","sentAt":"2024-10-03T00:23:17Z","receivedAt":"2024-10-03T00:23:31Z","isPatch":false,"sender":{"key":"sparr0@gmail.com","avatar":"https://gravatar.com/avatar/9fadd08c68a38b7d7c94e6a75f1a6702d9715ffdecd597418f27f7070dc77659?d=mp&s=160"},"body":"I found myself in a discussion online about where and how it is\nappropriate to ask git to ignore the .DS_Store file that is often\ncreated by macOS. This led me to considering disparities in the\ncurrent state of git-config and gitignore. In particular, git-config\nhas system-level configuration in $(prefix)/etc/gitconfig which can be\noverridden on a line by line basis by configuration at the user,\nrepository, or command levels. However, gitignore does not have an\nequivalent system-level layer. You can set core.excludesfile in the\nsystem-level config file, but the user can only override that whole\nfile by changing that config option, they have no way to override\nsingle exclude entries or even just add to the list for themselves at\nthe user (\"global\") level.\n\nI think that a system-level ignore/exclude file would be the ideal\nplace for the git package on a particular OS to put OS-specific rules\nlike the following examples, if they wanted to do so, or for a\nsysadmin or root user to do the same to cover all local accounts by\ndefault if their OS package opted to not provide any exclude rules.\nhttps://www.toptal.com/developers/gitignore/api/macos\nhttps://www.toptal.com/developers/gitignore/api/windows\nhttps://www.toptal.com/developers/gitignore/api/linux\n\nWas the decision to not allow or implement such a file intentional, or\nis it just an emergent property of the way the config system works and\nhow core.excludesFile was implemented? Would an implementation of a\nnew feature supporting this sort of thing be worth discussing?\n"},{"id":"504017","messageId":"Zv5SpewqUmlvhOl-@tapette.crustytoothpaste.net","threadId":"62245","inReplyTo":"CANp3UNCXqLJmAj2Vc7jB+i9qRjfKzrri_Mr9VvG4J5tUR-1HeQ@mail.gmail.com","subject":"Re: Lack of system-level excludesFile","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-03T08:15:33Z","receivedAt":"2024-10-03T08:15:36Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-03 at 00:23:17, Sparr wrote:\n> Was the decision to not allow or implement such a file intentional, or\n> is it just an emergent property of the way the config system works and\n> how core.excludesFile was implemented? Would an implementation of a\n> new feature supporting this sort of thing be worth discussing?\n\nI wasn't part of the project when the exclude functionality was\nimplemented, so I can't say what the intent was, but I will note that\neven CVS had ignore files.  My guess is that it wasn't seen as something\nuseful to implement, so nobody implemented it, but I think your argument\nfor doing so isn't bad.\n\nI'll just note that typically I ignore things in the global include\nwhich are likely to affect the environment I use, including my editor\nand operating system.  So when I was tutoring an Emacs user, we\nconfigured his machine to ignore `*~`, since his editor creates backup\nfiles, and likewise, if I were still using macOS, I'd ignore\n`.DS_Store`.\n\nSo basically, I think such a feature could be useful, but I also don't\nsee it as immediately necessary because the global (per-user) file is\nalso generally useful for this if the user is aware enough to know it\nexists (which I admit they might not be).  One thing I would request is\nthat if you add this, you add an appropriate var to `git var` so that\npeople can find the location, which is important because different\nversions of Git (say, Apple's vs. Homebrew's) may install the system\nconfiguration in different locations.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"504027","messageId":"xmqq34ldjiup.fsf@gitster.g","threadId":"62245","inReplyTo":"Zv5SpewqUmlvhOl-@tapette.crustytoothpaste.net","subject":"Re: Lack of system-level excludesFile","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-03T15:39:58Z","receivedAt":"2024-10-03T15:40:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> So basically, I think such a feature could be useful, but I also don't\n> see it as immediately necessary because the global (per-user) file is\n> also generally useful for this if the user is aware enough to know it\n> exists (which I admit they might not be).\n\nI was around ;-) and the reasoning is exactly that.  \n\nPer-user setting was considered the most appropriate (not \"good\nenough\", but \"more appropriate than system-wide\") primarily because\nthe exclude list generally is just as personal as it is personal\nwhat editor is used.\n\nThe same reason led to the thinking that it is perfectly fine to\nhave \"*~\" in the list of per-user exclude patterns for an Emacs user\nbut it is dubious to have in the list of system-wide exclude\npatterns, if such a thing existed, when the system is used also by a\nvi user.  I do not think it was explicitly argued, but it is natural\nto lead to the conclusion that it was not worth adding such a\nmechanism.\n\nAnd that led to recommendation that these patterns of personal\nnature should be left out of in-tree .gitignore file.  The Makefile\nand the project source would dictate what build artifacts are\nexpected to be created in the working tree of a checkout of a\nproject, and in-tree .gitignore is the perfect mechanism to mark\nthese *.o, *.a, and *.pyo files to be ignored, but because not\neverybody who work on the project uses Emacs, so \"*~\" falls into a\ndifferent category from these \"usual build artifacts\" and the\nrecommendation was to leave these outside the in-tree (or the list\nof system-wide patterns, if we had a mechanism to specify such a\nthing) .gitignore files.\n\nBut this thinking and recommendation changed over time, and I think\npeople (including us old-timers) take a more relaxed stance these\ndays.\n\nIf the contributor base of the project includes both Emacs and vi\nusers (and in this day and age of DEI, you are encourged to be\n\"inclusive\" and prepare for the folks from other camps to join the\nproject in the future, even if your contributor base is solely vi\nusers), it will not be likely that the project wants to have any\nfiles that match \"*~\" to be tracked at all, so having such a pattern\nin in-tree .gitignore file to be shared by all participants would\nnot hurt anybody.  Emacs users will be helped by not having to worry\nabout configuring their per-user configuration, and vi users won't\nbe hurt as they are not going to add a tracked file foo~ to the\nproject (and alienate their friends in the project who happen to use\nEmacs).\n\nIf you take the reasoning one step further [*], it may make sense to\nhave a list of ignored patterns that applies to everybody on the\nsystem, regardless of who they are, what editor they use, and what\nproject they work on.\n\nHaving said all that, wouldn't that be already supported?  What\nprevents you to set core.excludesFile in /etc/gitconfig?\n\nThanks.\n\n\n[Footnote]\n\n * This may be a larger step though, as the set of projects that a\n   single user works on is much narrower than the set of projects\n   that any users on the same system work on (hence the types of\n   files that are potentially tracked by these projects are much\n   wider for system-wide exclude list to take into consideration).\n\n   On the other hand, are massively multi-user systems (like the\n   time-shared system studends 30-years ago used at Universities)\n   still a thing?  If not, then having a pattern that may hurt\n   people with other preference on the system-wide list would not be\n   a problem at all---after all, you have the entire system without\n   anybody else.  But at that point, system-wide and per-user would\n   become the same thing ;-)\n\n"},{"id":"504035","messageId":"CANp3UNB_4_mcK4CV3WF7p3AWaLTK6qb13tS3imDBGU5XBOzG0A@mail.gmail.com","threadId":"62245","inReplyTo":"xmqq34ldjiup.fsf@gitster.g","subject":"Re: Lack of system-level excludesFile","fromName":"Sparr","fromEmail":"sparr0@gmail.com","sentAt":"2024-10-03T17:45:07Z","receivedAt":"2024-10-03T17:45:21Z","isPatch":false,"sender":{"key":"sparr0@gmail.com","avatar":"https://gravatar.com/avatar/9fadd08c68a38b7d7c94e6a75f1a6702d9715ffdecd597418f27f7070dc77659?d=mp&s=160"},"body":"On Thu, Oct 3, 2024 at 11:40 AM Junio C Hamano <gitster@pobox.com> wrote:\n> If you take the reasoning one step further [*], it may make sense to\n> have a list of ignored patterns that applies to everybody on the\n> system, regardless of who they are, what editor they use, and what\n> project they work on.\n>\n> Having said all that, wouldn't that be already supported?  What\n> prevents you to set core.excludesFile in /etc/gitconfig?\n\nI tried to cover this in my original email. You can set that and it\nwill apply to all users who haven't set up their own\ncore.excludesFile. But this has two problems.\n\n1. It will disable the default behavior of a user being able to put\ntheir own ignore rules in $XDG_CONFIG_HOME/git/ignore which I suspect\nmore than a few current git users rely on.\n\n2. As soon as a user sets core.excludesFile in their account-level\nconfig, to be able to create account-level ignore rules, such as based\non their desktop environment or editor or all the other stuff people\ntypically want to put in their excludesFile, they will lose the\nfunctionality provided by the system level ignore file.\n\n>  * This may be a larger step though, as the set of projects that a\n>    single user works on is much narrower than the set of projects\n>    that any users on the same system work on (hence the types of\n>    files that are potentially tracked by these projects are much\n>    wider for system-wide exclude list to take into consideration).\n\nI agree that these two scopes are very different, and that's why I\nwant to be able to set them both! ~Every user on a macOS computer\n(which might be a few on a family desktop, and was dozens last time I\nmanaged a macOS server) wants to ignore `.DS_Store`, `.AppleDouble`,\nand `.LSOverride` in ~every repo they work on.\n\n>    On the other hand, are massively multi-user systems (like the\n>    time-shared system studends 30-years ago used at Universities)\n>    still a thing?  If not, then having a pattern that may hurt\n>    people with other preference on the system-wide list would not be\n>    a problem at all---after all, you have the entire system without\n>    anybody else.  But at that point, system-wide and per-user would\n>    become the same thing ;-)\n\nThat's not quite true even on single-user computers. It's pretty\ncommon that one user might run things as their user account or as\nroot. It's less common but not unheard of for one user to have\nmultiple accounts (e.g. one for work and one for not work) or for\nnon-user accounts to perform git operations.\n"},{"id":"504054","messageId":"20241003212451.GA12763@coredump.intra.peff.net","threadId":"62245","inReplyTo":"CANp3UNB_4_mcK4CV3WF7p3AWaLTK6qb13tS3imDBGU5XBOzG0A@mail.gmail.com","subject":"Re: Lack of system-level excludesFile","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-10-03T21:24:51Z","receivedAt":"2024-10-03T21:24:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 03, 2024 at 01:45:07PM -0400, Sparr wrote:\n\n> On Thu, Oct 3, 2024 at 11:40 AM Junio C Hamano <gitster@pobox.com> wrote:\n> > If you take the reasoning one step further [*], it may make sense to\n> > have a list of ignored patterns that applies to everybody on the\n> > system, regardless of who they are, what editor they use, and what\n> > project they work on.\n> >\n> > Having said all that, wouldn't that be already supported?  What\n> > prevents you to set core.excludesFile in /etc/gitconfig?\n> \n> I tried to cover this in my original email. You can set that and it\n> will apply to all users who haven't set up their own\n> core.excludesFile. But this has two problems.\n> \n> 1. It will disable the default behavior of a user being able to put\n> their own ignore rules in $XDG_CONFIG_HOME/git/ignore which I suspect\n> more than a few current git users rely on.\n> \n> 2. As soon as a user sets core.excludesFile in their account-level\n> config, to be able to create account-level ignore rules, such as based\n> on their desktop environment or editor or all the other stuff people\n> typically want to put in their excludesFile, they will lose the\n> functionality provided by the system level ignore file.\n\nYeah, I agree that the current system is not quite flexible enough. And\nthere is some prior art already in /etc/gitattributes, which we respect\nin addition to core.attributesFile.\n\nI did wonder briefly if we could let core.excludesFile be a multi-valued\nlist (so you could add a user one on top of the system value). But that\nwould break backwards compatibility for people who expect the current\nlast-one-wins behavior. And also would interact weirdly with the XDG\nfallback, as you noted.\n\nSo I think it is reasonable to add a system-level version of gitignore.\nI'm not sure how often it would be used, but it certainly fills a gap\nand would make it consistent with config and attributes files. You can\ngrep for ETC_GITATTRIBUTES to see how the attributes version is\nconfigured and used.\n\n-Peff\n\nPS If you want to get really wild, consider this: the exclude/ignore\n   feature is really just a proper subset of the attributes system that\n   came later. If we were designing today, we could ditch .gitignore\n   entirely in favor of a special \"ignored\" attribute, and then you\n   could just use /etc/gitattributes to do what you want.\n\n   I'm not sure if people would find that more syntactically awkward; it\n   is nice that you can just dump files one per line into .gitignore\n   without special syntax. But it's possible that we could provide\n   _both_ mechanisms, and let the user do whichever they find easier.\n\n   That's obviously a much bigger project than just adding an\n   /etc/gitignore file, though. :)\n"},{"id":"504057","messageId":"xmqqh69shmwe.fsf@gitster.g","threadId":"62245","inReplyTo":"20241003212451.GA12763@coredump.intra.peff.net","subject":"Re: Lack of system-level excludesFile","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-03T21:55:29Z","receivedAt":"2024-10-03T21:55:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> PS If you want to get really wild, consider this: the exclude/ignore\n>    feature is really just a proper subset of the attributes system that\n>    came later. If we were designing today, we could ditch .gitignore\n>    entirely in favor of a special \"ignored\" attribute,\n\nYes, this was brought up in the past a few times.\n\nBoth the exclude stack (in dir.c) and attr stack (in attr.c) use a\nsimilar approach to optimize the accesses to the data for callers\nthat traverse the paths in-order and ask if something is ignored (or\nhas this attribute) for each of the paths they encounter, so their\nperformance characteristics might be similar.  It certainly is a\ntempting thought and indeed is a big project, especially if you want\nto keep some sort of backward compatibility ;-)\n"}]}