Re: [PUB]corrupt repos does not return error with `git fsck`

Faheem Mitha <faheem@faheem.info> writes:

OK, so the hash you got comes from a superproject which references it. My guess is that the superproject did a private commit in a submodule, added this submodule to the superproject, and forgot to push the submodule.

If so, it's a user error (that could arguably have been avoided with a better command-line interface, so Git is partly guilty), but not a repository corruption.

Not "a random hash", but a random abreviated hash. Look:

Changing the last digit:

$ git show 280c12ab49223c64c6f914944287a7d049cf4d23 fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4d23 $ git show 280c12ab49223c64c6f914944287a7d049cf4d24 fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4d24 $ git show 280c12ab49223c64c6f914944287a7d049cf4d25 fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4d25 $ git show 280c12ab49223c64c6f914944287a7d049cf4d26 fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4d26

Removing the last digit:

$ git show 280c12ab49223c64c6f914944287a7d049cf4d2 fatal: ambiguous argument '280c12ab49223c64c6f914944287a7d049cf4d2': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'