inconsistent `git reflog show` output, possibly `git fsck` output

Hello,

When trying out Roberto Tyley's BFG Repo-Cleaner program [1], I managed to put a git repository in the following state:

    [2] fs@erdos /tmp/bfg-test-repo $ cat .git/logs/HEAD
    0000000000000000000000000000000000000000 00afb9f9a0c87dba4a203413358984e9f4fa5ffb Keshav Kini <[email protected]> 1379746570 -0500	clone: from /home/fs/work/x86
    [2] fs@erdos /tmp/bfg-test-repo $ git rev-parse HEAD
    a29caa4646698bcf2273cc60d3d612593b4ced8f
    [2] fs@erdos /tmp/bfg-test-repo $ git reflog | cat
    a29caa4 (HEAD, refs/remotes/origin/HEAD, refs/remotes/origin/32-bit-accesses, refs/heads/32-bit-accesses) HEAD@{0}: clone: from /home/fs/work/x86
    [2] fs@erdos /tmp/bfg-test-repo $ git fsck
    Checking object directories: 100% (256/256), done.
    Checking objects: 100% (6635/6635), done.
    [2] fs@erdos /tmp/bfg-test-repo $ echo $?
    0

This situation came about because the BFG Repo-Cleaner doesn't write new reflog entries after creating its new objects and moving refs around. But that aside, I think how git handles the situation might be a bug.

As you can see, HEAD is currently at a29caa46, but the reflog's data file .git/logs/HEAD doesn't describe how it came to be at a29caa46. The single reflog entry describes how the HEAD pointer was initialized to 00afb9f9 when I cloned the repository from /home/fs/work/x86 .

By the wording of the git reflog man page, I would assume that the lines displayed by git reflog show HEAD would correspond to a chain of reflog entries, where the short commit ID at the beginning of each line would represent the second field of the reflog entry in question, and the first field of the reflog entry would correspond to the short commit ID at the beginning of the line directly below. For example, if git reflog show HEAD displayed this:

    0123456 [stuff] foo
    789abcd [stuff] bar
    ef01234 [stuff] baz

Then I would expect the reflog data file for HEAD to look something like this, where '.' represents an unknown hex digit:

    789abcd................................. 0123456................................. [stuff]
    ef01234................................. 789abcd................................. [stuff]
    ........................................ ef01234................................. [stuff]

However, in this example, the short commit ID shown in git reflog show doesn't even appear in the reflog data file!

It seems to me that one of two things should be the case. Either 1) it should be considered impossible to have a reflog for a ref X which doesn't contain a chain of commits leading up to the current location of X; or 2) if reflogs are allowed not to form an unbroken chain of commits leading to X, then git reflog show should at least make sure to actually display a commit ID corresponding to the second field of each reflog entry it reads, and not some other commit ID.

In the first case, the bug is that git fsck doesn't catch the supposedly impossible situation that exists in the repository I've described in this email. In the second case, the bug is that git reflog show has bad output.

I'm reporting this because I was having difficulty figuring out why git gc was not collecting the commit 00afb9f. The reason turned out to be that it was mentioned in a reflog and thus not getting pruned, which would have been much easier to discover had the output of git reflog show mentioned 00afb9f at all.

Please let me know what you think.

Thanks,
Keshav

[1] http://rtyley.github.io/bfg-repo-cleaner/

True enough - I don't think the BFG does write new entires to the
reflog when it does the final ref-update, and it would be nicer if it did. I'll get that fixed.

thanks,
Roberto

(sorry for replying late)

So this can be closed as "BFG not writing reflog in a consistent way, and 'git reflog show' is acting GIGO way"? Or was there something the core side needs to do?

Hi Junio,

Thanks for your reply. In my original mail, immediately after the snippet Roberto quoted above, I said, "But that aside, I think how git handles the situation might be a bug." To wit:

Before this is closed, I would appreciate it if I could get some feedback from git developers on the above two paragraphs.

Thanks,
Keshav

Hi Junio,

Below I'm resending a mail that I sent to the list earlier, but not to you or Roberto personally, as I just realized. So in case you didn't see it before, here it is -- if you did see it before, sorry for the noise.

Hi Junio,

Thanks for your reply. In my original mail, immediately after the snippet Roberto quoted above, I said, "But that aside, I think how git handles the situation might be a bug." To wit:

Before this is closed, I would appreciate it if I could get some feedback from git developers on the above two paragraphs.

Thanks,
Keshav

Sorry, that's backwards -- I would actually expect this:

    ........................................ ef01234................................. [stuff]
    ef01234................................. 789abcd................................. [stuff]
    789abcd................................. 0123456................................. [stuff]

-Keshav