{"thread":{"id":"56756","subject":"gitignore as symbolic link","startedAt":"2021-10-22T01:16:20Z","lastAt":"2021-10-23T20:51:34Z","messageCount":8,"participants":["Justus Ranvier","Rene Kita","Matheus Tavares","brian m. carlson","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439321","messageId":"fcf288fc-72b7-964c-e462-496066528c7b@opentransactions.org","threadId":"56756","inReplyTo":null,"subject":"gitignore as symbolic link","fromName":"Justus Ranvier","fromEmail":"justus@opentransactions.org","sentAt":"2021-10-22T01:07:44Z","receivedAt":"2021-10-22T01:16:20Z","isPatch":false,"sender":{"key":"justus@opentransactions.org","avatar":null},"body":"I have several repositories where the top level .gitignore file is a \nsymbolic link to the actual file which is contained in a submodule which \nall the repositories share.\n\nThis worked fine up to and including version 2.31.1 but as of 2.32.0 \nrunning any command which would cause .gitignore to be read results in a \n\"too many levels of symbolic links error\" and git behaves as if \n.gitignore is not present.\n"},{"id":"439392","messageId":"YXLro/8c1Feg6TcN@kitchen","threadId":"56756","inReplyTo":"fcf288fc-72b7-964c-e462-496066528c7b@opentransactions.org","subject":"Re: gitignore as symbolic link","fromName":"Rene Kita","fromEmail":"mail@rkta.de","sentAt":"2021-10-22T16:49:39Z","receivedAt":"2021-10-22T16:57:06Z","isPatch":false,"sender":{"key":"mail@rkta.de","avatar":null},"body":"On Thu, Oct 21, 2021 at 05:07:44PM -0800, Justus Ranvier wrote:\n> I have several repositories where the top level .gitignore file is a\n> symbolic link to the actual file which is contained in a submodule which all\n> the repositories share.\n> \n> This worked fine up to and including version 2.31.1 but as of 2.32.0 running\n> any command which would cause .gitignore to be read results in a \"too many\n> levels of symbolic links error\" and git behaves as if .gitignore is not\n> present.\n> \nThis was fixed in commit a185dd58ecc17f2ea16985d59c9bb7b09bec7775 [1].\n\n[1] https://lore.kernel.org/git/xmqqlf83h2a7.fsf@gitster.g/\n"},{"id":"439432","messageId":"CAHd-oW50puNCrYTQhR4qffgtP6-wJerWLhmhCV+nYcLVNu+CBg@mail.gmail.com","threadId":"56756","inReplyTo":"YXLro/8c1Feg6TcN@kitchen","subject":"Re: gitignore as symbolic link","fromName":"Matheus Tavares","fromEmail":"matheus.bernardino@usp.br","sentAt":"2021-10-22T22:40:53Z","receivedAt":"2021-10-22T22:41:08Z","isPatch":false,"sender":{"key":"matheus.tavb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701583?v=4"},"body":"On Fri, Oct 22, 2021 at 1:57 PM Rene Kita <mail@rkta.de> wrote:\n>\n> On Thu, Oct 21, 2021 at 05:07:44PM -0800, Justus Ranvier wrote:\n> > I have several repositories where the top level .gitignore file is a\n> > symbolic link to the actual file which is contained in a submodule which all\n> > the repositories share.\n> >\n> > This worked fine up to and including version 2.31.1 but as of 2.32.0 running\n> > any command which would cause .gitignore to be read results in a \"too many\n> > levels of symbolic links error\" and git behaves as if .gitignore is not\n> > present.\n> >\n> This was fixed in commit a185dd58ecc17f2ea16985d59c9bb7b09bec7775 [1].\n\nHmm, the behavior Justus described is actually related to another\nchange. Since v2.32.0, git no longer follows \".gitattributes\",\n\".gitignore\" and \".mailmap\" if they are symbolic links. It does that\nby open()-ing these files with the O_NOFOLLOW flag, which returns\nELOOP (\"too many levels of symbolic links error\") when the basename is\na symlink. So the behavior you experienced is actually not a bug, but\nan intended change.\n\nFor a full explanation please see a2ef579e261 (\"attr: do not respect\nsymlinks for in-tree .gitattributes\", 2021-02-16) [2] and feb9b7792f\n(\"exclude: do not respect symlinks for in-tree .gitignore\",\n2021-02-16) [3].\n\nBut the short version is: git accesses these files either from the\nworking tree or the object store (think, e.g. a bare repo). Git never\nfollows symlinks in the second case, so following them on the working\ntree was an inconsistent behavior which was fixed. (This also has a\nsecurity implication, in the sense that it could be dangerous to\nfollow symlinks that lead to paths outside the repository.)\n\nNote that \"core.excludesFile\" and \"$GIT_DIR/info/exclude\" are still\nallowed to be symlinks.\n\n[2]: https://github.com/git/git/commit/2ef579e261\n[3]: https://github.com/git/git/commit/feb9b7792f\n\n> [1] https://lore.kernel.org/git/xmqqlf83h2a7.fsf@gitster.g/\n"},{"id":"439436","messageId":"bf0e854b-0018-460c-adc5-289108713f04@opentransactions.org","threadId":"56756","inReplyTo":"CAHd-oW50puNCrYTQhR4qffgtP6-wJerWLhmhCV+nYcLVNu+CBg@mail.gmail.com","subject":"Re: gitignore as symbolic link","fromName":"Justus Ranvier","fromEmail":"justus@opentransactions.org","sentAt":"2021-10-22T23:29:04Z","receivedAt":"2021-10-22T23:30:12Z","isPatch":false,"sender":{"key":"justus@opentransactions.org","avatar":null},"body":"On 10/22/21 14:40, Matheus Tavares wrote:\n> So the behavior you experienced is actually not a bug, but\n> an intended change.\n\nSo it's a permanent loss of functionality that I just have to live with. \nGot it.\n"},{"id":"439437","messageId":"fa4b28b1-9b5e-0201-5afe-2e8f294fa9b4@opentransactions.org","threadId":"56756","inReplyTo":"CAHd-oW50puNCrYTQhR4qffgtP6-wJerWLhmhCV+nYcLVNu+CBg@mail.gmail.com","subject":"Re: gitignore as symbolic link","fromName":"Justus Ranvier","fromEmail":"justus@opentransactions.org","sentAt":"2021-10-22T23:55:16Z","receivedAt":"2021-10-23T00:03:52Z","isPatch":false,"sender":{"key":"justus@opentransactions.org","avatar":null},"body":"Suppose a person is managing N repositories. Would that person prefer to \nmaintain the list of files to ignore for every random IDE that anybody \nwho joins the team might want to use in:\n\na: One place\nb: N places\n\n\nOn 10/22/21 14:40, Matheus Tavares wrote:\n> Note that \"core.excludesFile\" and \"$GIT_DIR/info/exclude\" are still\n> allowed to be symlinks.\n\nThese are settings that are specific to each developer, right?\n\nIf I have N repositories with M developers and I need to add a new \nignore pattern that's either and O(M) or an O(N) job, neither of which \nis significantly better than the other and both of which suck compared \nto the O(1) functionality that we had before when we could put the list \non a shared submodule.\n\n"},{"id":"439446","messageId":"YXP5rZT5IgFcMZs0@camp.crustytoothpaste.net","threadId":"56756","inReplyTo":"fa4b28b1-9b5e-0201-5afe-2e8f294fa9b4@opentransactions.org","subject":"Re: gitignore as symbolic link","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-23T12:01:49Z","receivedAt":"2021-10-23T12:02:37Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-22 at 23:55:16, Justus Ranvier wrote:\n> Suppose a person is managing N repositories. Would that person prefer to\n> maintain the list of files to ignore for every random IDE that anybody who\n> joins the team might want to use in:\n> \n> a: One place\n> b: N places\n\nDevelopers should be responsible for ensuring that their own editor's\ntemporary files are ignored.  For example, I use Vim, so it's my\nresponsibility to ensure that I globally ignore swap files using\n\"core.excludesFile\" or that my editor is configured not to produce them.\n(In my case, it's the latter.)\n\nAs you point out, it's unsustainable to have to manage a list of the\ndetritus of every possible editor.  What if I had decided to use an\neditor that is not very popular, like ae, joe, or acme?  Should every\nproject be responsible for dealing with my uncommon editor, or should I\nbe responsible for my own editing hygiene?\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439451","messageId":"e5a6dfa5-617f-5b5b-6803-45d36b3de53e@opentransactions.org","threadId":"56756","inReplyTo":"YXP5rZT5IgFcMZs0@camp.crustytoothpaste.net","subject":"Re: gitignore as symbolic link","fromName":"Justus Ranvier","fromEmail":"justus@opentransactions.org","sentAt":"2021-10-23T15:40:52Z","receivedAt":"2021-10-23T15:41:59Z","isPatch":false,"sender":{"key":"justus@opentransactions.org","avatar":null},"body":"On 10/23/21 04:01, brian m. carlson wrote:\n> For example, I\n\nI'm glad that works for you and whatever organizations you happen to be \ninvolved in. I'm sure you're happy that git taking away this capability \ndid not impact your workflow.\n\nOther people have different use cases and operate under different sets \nof constraints and are considerably inconvenienced when functionality \nthat has worked for many years is suddenly removed from a core piece of \nsoftware like git.\n"},{"id":"439455","messageId":"211023.86k0i3ihwz.gmgdl@evledraar.gmail.com","threadId":"56756","inReplyTo":"e5a6dfa5-617f-5b5b-6803-45d36b3de53e@opentransactions.org","subject":"Re: gitignore as symbolic link","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-23T20:49:05Z","receivedAt":"2021-10-23T20:51:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Oct 23 2021, Justus Ranvier wrote:\n\n> On 10/23/21 04:01, brian m. carlson wrote:\n>> For example, I\n>\n> I'm glad that works for you and whatever organizations you happen to\n> be involved in. I'm sure you're happy that git taking away this\n> capability did not impact your workflow.\n>\n> Other people have different use cases and operate under different sets\n> of constraints and are considerably inconvenienced when functionality \n> that has worked for many years is suddenly removed from a core piece\n> of software like git.\n\nI've workd on repos that had the union of every editor tempfile under\nthe sun in the .gitignore, it didn't really cause any practical\nproblems, they tend not to conflict with \"real\" filenames.\n\nAs for the .gitignore problem I think it's very much in the state of\n\"patches welcome\", see a previous summary of mine at :\nhttps://lore.kernel.org/git/87o8c34dq6.fsf@evledraar.gmail.com/\n\nI.e. I don't think anyone should consider the current behavior to be set\nin stone, and certainly not when it comes to potential opt-in\nconfiguration.\n"}]}