Hey!
Its been a minute since I've written to the list but I was recently looking
into the rules fsck uses to identify valid or invalid objects and I believe I
found a case that I believe fsck is currently missing. One of the things fsck
looks for when validating a tree object is that it doesn't contain any
duplicate entries. It even has a nice comment about how `git-write-tree` used
to write out trees with duplicate entries:
/*
* git-write-tree used to write out a nonsense tree that has
* entries with the same name, one blob and one tree. Make
* sure we do not have duplicate entries.
*/
Here's the setup:
tree c63d067eaeed0cbc68b7e4fdf40d267c6b152fe8
tree 6241ab2a5314798183b5c4ee8a7b0ccd12c651e6
blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689
$ git ls-tree c63d067eaeed0cbc68b7e4fdf40d267c6b152fe8
100644 blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 hello
100644 blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 hello.c
040000 tree 6241ab2a5314798183b5c4ee8a7b0ccd12c651e6 hello
$ git ls-tree 6241ab2a5314798183b5c4ee8a7b0ccd12c651e6
100644 blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 hello
# '%' here indicates that there is no newline at the end of the object
$ git cat-file blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689
Hello World%
fsck currently passes when being passed these objects despite c63d067eae having
a duplicate entry. This seems to be due to the duplicate entry check in
`fsck_tree` only checking if adjacent entries are duplicates but due to the
sorting rules its unable to realize that there is both a blob and a tree with
the name "hello".
I was even able to produce a commit and push it to Github[1] (which
didn't complain)
$ git show --pretty=raw 62f1ff6e109f8b77edd7eeb65f6634faa76a93b2
commit 62f1ff6e109f8b77edd7eeb65f6634faa76a93b2
tree c63d067eaeed0cbc68b7e4fdf40d267c6b152fe8
author Brandon Williams <bwilliams.eng@xxxxxxxxx> 1589004242 -0700
committer Brandon Williams <bwilliams.eng@xxxxxxxxx> 1589004242 -0700
hello
Checking out that commit leaves your working directory in a somewhat
broken and 'unclean' state (although Github's UI seems to be able to handle
displaying it properly).
Am I correct in assuming that this object is indeed invalid and should be
rejected by fsck?
-Brandon
[1]: https://github.com/bmwill/invalid-commit
