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

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

[Keshav Kini]

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 <keshav.kini@gmail.com> 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/

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

[Keshav Kini]

Keshav Kini <keshav.kini@gmail.com> writes:
> 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]

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

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

-Keshav

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

[Roberto Tyley]

On 21/09/2013 23:16, Keshav Kini wrote:
> [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.

thanks,
Roberto

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

[Junio C Hamano]

Roberto Tyley <roberto.tyley@gmail.com> writes:

> On 21/09/2013 23:16, Keshav Kini wrote:
>> [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?

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

[Keshav Kini]

Junio C Hamano <gitster@pobox.com> writes:

> Roberto Tyley <roberto.tyley@gmail.com> writes:
>
>> On 21/09/2013 23:16, Keshav Kini wrote:
>>> [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

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

[Keshav Kini]

Junio C Hamano <gitster@pobox.com> writes:
> Roberto Tyley <roberto.tyley@gmail.com> writes:
>> On 21/09/2013 23:16, Keshav Kini wrote:
>>> [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,

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:

> 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