On Sep 23, 2010, at 1:35 PM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Sep 23, 2010 at 20:13, Kevin Ballard <kevin@xxxxxx> wrote: > >> Attempting to use `git reflog show foo` or `git log -g foo` will >> bail with "bad object: foo" if the tip commit of foo is >> invalid. This seems incredibly non-useful. Why should reflog care if >> foo points to a valid commit? This bug prevents reflog from being >> used in a time of great need, which someone just ran into on the >> #git IRC channel. Their power cut out and they ended up with a >> corrupt commit on the tip of their branch, and they simply could not >> view the reflog, which would have enabled them to roll the branch >> back to a previous commit. Does anybody know why reflog has this >> behavior? > > As you say the repository is probably corrupted, and recovering from > that may be hard, not much you can do with corrupted data. > > Can this person provide a tar-ed copy of the repository so we can look > at it and be of help, instead of speculating? The person's problem was eventually resolved by finding another clone of the repository and using it to identify the bad object. However, I was able to trivially reproduce the reflog problem by making a very simple history, then modifying the ref itself to point to a bad hash (I merely incremented the hash by 1). At this point, attempting to say `git reflog show foo` was complaining "fatal: Bad object foo" even though the reflog itself is perfectly valid, and in fact the only problem in the entire repository is the ref currently points to a hash that doesn't exist in the object database. -Kevin Ballard-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html