Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output

Junio C Hamano [off-list ref] writes:

Roberto Tyley [off-list ref] writes:

quoted

On 21/09/2013 23:16, Keshav Kini wrote:

quoted

[SNIP]
This situation came about because the BFG Repo-Cleaner doesn't write new
reflog entries after creating its new objects and moving refs around.

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.

(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:

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.

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

Thanks,
    Keshav