On Sep 23, 2010, at 2:57 PM, Kevin Ballard wrote:
> 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.
It appears the problem is `git reflog show` uses the current value of the branch as the first entry in the reflog, rather than actually showing the latest entry in the reflog. It still uses the message from the latest reflog entry, but the commit hash shown is the actual value of the branch. Is there any reason for this behavior? I admit it may be confusing if the reflog for a branch doesn't actually show the current branch pointer, but that should not be possible under normal behavior, and in a corrupt repo I believe showing the reflog is more important than showing the branch pointer. If necessary, we could even make it display a warning in this case.
Curiously, when the branch points to a commit not in the reflog, running `git rev-parse master@{0}` gives me something like
warning: Log .git/logs/refs/heads/master unexpectedly ended on Thu, 23 Sep 2010 13:09:56 -0700.
d73cfd127a564756f7790d2c4ae00af0126ead29
Note that the hash it shows is actually the current value of the branch rather than the latest reflog entry. Arguably, this should also use the reflog unambiguously, as again, under normal operations that should be identical to the current branch, and with a corrupt repo the user may care more about the reflog. I can't think of any scenario where I would expect master@{0} to give me back the master branch if it differs from what the reflog says.
My proposal is twofold. First, modify `git reflog show` to only show the reflog and to not even attempt to show the current commit. It may also be worth extending it to not fail when it hits a bad object, but to simply log that and continue. And second, modify master@{0} to show the reflog entry in the event where it doesn't match the current value of the branch. Any comments/suggestions on this?
-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