On Tue, Mar 10, 2020 at 11:41 AM Jörn Engel <joern@xxxxxxxxxxxxxxx> wrote: > > Something weird happened to us and I have no idea how to reproduce it. > A developer managed to create a git commit with the following content: > > diff --git a/foo b/foo > new file mode 160000 > index 000000000000..b7e7816c1266 > --- /dev/null > +++ b/foo > @@ -0,0 +1 @@ > +one line of content > > File name and content obfuscated, the rest is verbatim from the git > commit. > > Now, file mode 160000 doesn't make sense to me. It doesn't correspond > to any known file type and I cannot explain how this commit was created > in the first place. But whatever the mechanism, the git client should > have refused it. Git's file modes aren't (entirely) real. It doesn't actually track read/write, for example, but it does use the mode to track executable. That means, for normal files, the possible modes are 0755 and 0644. Other modes like 0600 or 0750 or similar are not possible. But Git also uses the mode as a way to track other things. In this case, 160000 means the file is _intended_ to be a submdule (albeit with what appears to be invalid content for a submodule, in this case). Relevant source: https://github.com/git/git/blob/master/cache.h#L69 > > Next, the commit was pushed to our git server, which happily accepted > it. Again, I would argue that the git server should have refused the > push. Since 160000 is a valid mode _to Git_, the push is fine. > > Finally, others including myself pulled and checked out a branch with > this commit. On checkout, an empty directory is being created and > caused various mayhem. I get: > error: 'foo' does not have a commit checked out > fatal: updating files failed This indicates, as I mentioned earlier, that the contents of the "foo" submodule are invalid, so Git couldn't actually check it out. The content is expected to be the SHA of a commit, paired with a matching line in a `.gitmodules` file which tells Git where the repository is so it can check it out. > > Not sure what the correct solution would be here. An empty directory is > a bad idea, but I cannot think of any "correct" way to handle things > once the bad commit is in the tree. It should be straightforward to delete the broken submodule (git rm foo), commit and push. Hope this helps! Bryan > > In case it matters, my client is: git version 2.25.0 > > Jörn
