{"thread":{"id":"52971","subject":"new file mode 160000","startedAt":"2020-03-10T18:41:18Z","lastAt":"2020-03-11T18:35:51Z","messageCount":9,"participants":["Jörn Engel","Andreas Schwab","Bryan Turner","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"393028","messageId":"20200310184111.GD1443@cork","threadId":"52971","inReplyTo":null,"subject":"new file mode 160000","fromName":"Jörn Engel","fromEmail":"joern@purestorage.com","sentAt":"2020-03-10T18:41:11Z","receivedAt":"2020-03-10T18:41:18Z","isPatch":false,"sender":{"key":"joern@purestorage.com","avatar":null},"body":"Something weird happened to us and I have no idea how to reproduce it.\nA developer managed to create a git commit with the following content:\n\ndiff --git a/foo b/foo\nnew file mode 160000\nindex 000000000000..b7e7816c1266\n--- /dev/null\n+++ b/foo\n@@ -0,0 +1 @@\n+one line of content\n\nFile name and content obfuscated, the rest is verbatim from the git\ncommit.\n\nNow, file mode 160000 doesn't make sense to me. It doesn't correspond\nto any known file type and I cannot explain how this commit was created\nin the first place. But whatever the mechanism, the git client should\nhave refused it.\n\nNext, the commit was pushed to our git server, which happily accepted\nit. Again, I would argue that the git server should have refused the\npush.\n\nFinally, others including myself pulled and checked out a branch with\nthis commit. On checkout, an empty directory is being created and\ncaused various mayhem. I get:\n\terror: 'foo' does not have a commit checked out\n\tfatal: updating files failed\n\nNot sure what the correct solution would be here. An empty directory is\na bad idea, but I cannot think of any \"correct\" way to handle things\nonce the bad commit is in the tree.\n\nIn case it matters, my client is: git version 2.25.0\n\nJörn\n\n--\nSo, one might well ask, if Congress and the White House, Republicans\nand Democrats, liberals and conservatives, all now agree on reform,\nhow meaningful can the reform be?\n-- David Cole\n"},{"id":"393031","messageId":"87lfo8m3fu.fsf@igel.home","threadId":"52971","inReplyTo":"20200310184111.GD1443@cork","subject":"Re: new file mode 160000","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2020-03-10T19:10:13Z","receivedAt":"2020-03-10T19:10:18Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Mär 10 2020, Jörn Engel wrote:\n\n> Something weird happened to us and I have no idea how to reproduce it.\n> A developer managed to create a git commit with the following content:\n>\n> diff --git a/foo b/foo\n> new file mode 160000\n> index 000000000000..b7e7816c1266\n> --- /dev/null\n> +++ b/foo\n> @@ -0,0 +1 @@\n> +one line of content\n>\n> File name and content obfuscated, the rest is verbatim from the git\n> commit.\n>\n> Now, file mode 160000 doesn't make sense to me.\n\n0160000 is S_IFLNK in MiNT\n.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"393033","messageId":"CAGyf7-GoJNtdPT=GWG-QcP=J6uu1un5drvPAcNr5jB9Sc_ZLRg@mail.gmail.com","threadId":"52971","inReplyTo":"20200310184111.GD1443@cork","subject":"Re: new file mode 160000","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-03-10T19:37:14Z","receivedAt":"2020-03-10T19:37:27Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Tue, Mar 10, 2020 at 11:41 AM Jörn Engel wrote:\n>\n> Something weird happened to us and I have no idea how to reproduce it.\n> A developer managed to create a git commit with the following content:\n>\n> diff --git a/foo b/foo\n> new file mode 160000\n> index 000000000000..b7e7816c1266\n> --- /dev/null\n> +++ b/foo\n> @@ -0,0 +1 @@\n> +one line of content\n>\n> File name and content obfuscated, the rest is verbatim from the git\n> commit.\n>\n> Now, file mode 160000 doesn't make sense to me. It doesn't correspond\n> to any known file type and I cannot explain how this commit was created\n> in the first place. But whatever the mechanism, the git client should\n> have refused it.\n\nGit's file modes aren't (entirely) real. It doesn't actually track\nread/write, for example, but it does use the mode to track executable.\nThat means, for normal files, the possible modes are 0755 and 0644.\nOther modes like 0600 or 0750 or similar are not possible.\n\nBut Git also uses the mode as a way to track other things. In this\ncase, 160000 means the file is _intended_ to be a submdule (albeit\nwith what appears to be invalid content for a submodule, in this\ncase). Relevant source:\nhttps://github.com/git/git/blob/master/cache.h#L69\n\n>\n> Next, the commit was pushed to our git server, which happily accepted\n> it. Again, I would argue that the git server should have refused the\n> push.\n\nSince 160000 is a valid mode _to Git_, the push is fine.\n\n>\n> Finally, others including myself pulled and checked out a branch with\n> this commit. On checkout, an empty directory is being created and\n> caused various mayhem. I get:\n> error: 'foo' does not have a commit checked out\n> fatal: updating files failed\n\nThis indicates, as I mentioned earlier, that the contents of the \"foo\"\nsubmodule are invalid, so Git couldn't actually check it out. The\ncontent is expected to be the SHA of a commit, paired with a matching\nline in a `.gitmodules` file which tells Git where the repository is\nso it can check it out.\n\n>\n> Not sure what the correct solution would be here. An empty directory is\n> a bad idea, but I cannot think of any \"correct\" way to handle things\n> once the bad commit is in the tree.\n\nIt should be straightforward to delete the broken submodule (git rm\nfoo), commit and push.\n\nHope this helps!\nBryan\n>\n> In case it matters, my client is: git version 2.25.0\n>\n> Jörn\n"},{"id":"393034","messageId":"xmqqsgighu2p.fsf@gitster.c.googlers.com","threadId":"52971","inReplyTo":"20200310184111.GD1443@cork","subject":"Re: new file mode 160000","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-10T19:46:06Z","receivedAt":"2020-03-10T19:46:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jörn Engel writes:\n\n> Something weird happened to us and I have no idea how to reproduce it.\n> A developer managed to create a git commit with the following content:\n>\n> diff --git a/foo b/foo\n> new file mode 160000\n> index 000000000000..b7e7816c1266\n> --- /dev/null\n> +++ b/foo\n> @@ -0,0 +1 @@\n> +one line of content\n>\n> File name and content obfuscated, the rest is verbatim from the git\n> commit.\n>\n> Now, file mode 160000 doesn't make sense to me.\n\nThese are gitlinks, that are used to implement submodules. I cannot\ntell if this is an expected behaviour and there is nothing to worry\nabout, or you found a corner case bug, without looking at what the\n\"one line of content\" says, but if it says \"Subproject commit \"\nfollowed by 40-hex object name, then that is a perfectly normal\nbehaviour.\n\nAfter doing these:\n\n\tgit init bar\n\tcd bar\n\tgit init foo\n\tcd foo ;# in bar/foo\n\tgit commit --allow-empty -m initial\n\tcd .. ;# back in bar\n\tgit add foo\n\tgit commit -m add\n\tgit show\n\nanybody who has a working Git would see the \"diff --git\" that shows 160000\nyou showed above.\n\n\n"},{"id":"393035","messageId":"xmqqo8t4hu0n.fsf@gitster.c.googlers.com","threadId":"52971","inReplyTo":"87lfo8m3fu.fsf@igel.home","subject":"Re: new file mode 160000","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-10T19:47:20Z","receivedAt":"2020-03-10T19:47:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> On Mär 10 2020, Jörn Engel wrote:\n>\n>> Something weird happened to us and I have no idea how to reproduce it.\n>> A developer managed to create a git commit with the following content:\n>>\n>> diff --git a/foo b/foo\n>> new file mode 160000\n>> index 000000000000..b7e7816c1266\n>> --- /dev/null\n>> +++ b/foo\n>> @@ -0,0 +1 @@\n>> +one line of content\n>>\n>> File name and content obfuscated, the rest is verbatim from the git\n>> commit.\n>>\n>> Now, file mode 160000 doesn't make sense to me.\n>\n> 0160000 is S_IFLNK in MiNT\n> .\n\nYeek. That sounds like a ticking time-bomb.\n\n"},{"id":"393037","messageId":"20200310195724.GE1443@cork","threadId":"52971","inReplyTo":"xmqqsgighu2p.fsf@gitster.c.googlers.com","subject":"Re: new file mode 160000","fromName":"Jörn Engel","fromEmail":"joern@purestorage.com","sentAt":"2020-03-10T19:57:24Z","receivedAt":"2020-03-10T19:57:30Z","isPatch":false,"sender":{"key":"joern@purestorage.com","avatar":null},"body":"On Tue, Mar 10, 2020 at 12:46:06PM -0700, Junio C Hamano wrote:\n> Jörn Engel writes:\n> \n> > Something weird happened to us and I have no idea how to reproduce it.\n> > A developer managed to create a git commit with the following content:\n> >\n> > diff --git a/foo b/foo\n> > new file mode 160000\n> > index 000000000000..b7e7816c1266\n> > --- /dev/null\n> > +++ b/foo\n> > @@ -0,0 +1 @@\n> > +one line of content\n> >\n> > File name and content obfuscated, the rest is verbatim from the git\n> > commit.\n> >\n> > Now, file mode 160000 doesn't make sense to me.\n> \n> These are gitlinks, that are used to implement submodules. I cannot\n> tell if this is an expected behaviour and there is nothing to worry\n> about, or you found a corner case bug, without looking at what the\n> \"one line of content\" says, but if it says \"Subproject commit \"\n> followed by 40-hex object name, then that is a perfectly normal\n> behaviour.\n\nThat is indeed the content. So no bug in git. Thank you!\n\nGiven that we don't want to use submodules for this particular\nproject, can the git server be configured to refuse push requests that\nwould introduce submodules?\n\nJörn\n\n--\nThis above all: to thine own self be true.\n-- Shakespeare\n"},{"id":"393038","messageId":"87h7ywm0p2.fsf@igel.home","threadId":"52971","inReplyTo":"xmqqo8t4hu0n.fsf@gitster.c.googlers.com","subject":"Re: new file mode 160000","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2020-03-10T20:09:29Z","receivedAt":"2020-03-10T20:09:36Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Mär 10 2020, Junio C Hamano wrote:\n\n> Andreas Schwab writes:\n>\n>> On Mär 10 2020, Jörn Engel wrote:\n>>\n>>> Something weird happened to us and I have no idea how to reproduce it.\n>>> A developer managed to create a git commit with the following content:\n>>>\n>>> diff --git a/foo b/foo\n>>> new file mode 160000\n>>> index 000000000000..b7e7816c1266\n>>> --- /dev/null\n>>> +++ b/foo\n>>> @@ -0,0 +1 @@\n>>> +one line of content\n>>>\n>>> File name and content obfuscated, the rest is verbatim from the git\n>>> commit.\n>>>\n>>> Now, file mode 160000 doesn't make sense to me.\n>>\n>> 0160000 is S_IFLNK in MiNT\n>> .\n>\n> Yeek. That sounds like a ticking time-bomb.\n\nconfigure can detect that (NEEDS_MODE_TRANSLATION).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"393046","messageId":"20200310222256.GA6198@camp.crustytoothpaste.net","threadId":"52971","inReplyTo":"20200310195724.GE1443@cork","subject":"Re: new file mode 160000","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-03-10T22:22:56Z","receivedAt":"2020-03-10T22:23:03Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-03-10 at 19:57:24, Jörn Engel wrote:\n> That is indeed the content. So no bug in git. Thank you!\n> \n> Given that we don't want to use submodules for this particular\n> project, can the git server be configured to refuse push requests that\n> would introduce submodules?\n\nI don't believe there's an option to do this, but it could be achieved\nwith a pre-receive hook. That's the usual approach for denying pushes\ncontaining unwanted data (submodules, large files, commits with\nimproperly formatted messages, etc.).\n\nIf your Git server doesn't let you install pre-receive hooks, you can do\nthis by adding a test to your CI system to reject objectionable pushes.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"393064","messageId":"xmqq1rpyivsv.fsf@gitster.c.googlers.com","threadId":"52971","inReplyTo":"87h7ywm0p2.fsf@igel.home","subject":"Re: new file mode 160000","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-11T18:35:44Z","receivedAt":"2020-03-11T18:35:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n>>> 0160000 is S_IFLNK in MiNT\n>>> .\n>>\n>> Yeek. That sounds like a ticking time-bomb.\n>\n> configure can detect that (NEEDS_MODE_TRANSLATION).\n\nThanks--I totally forgot about that one.\n"}]}