# [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output 6 messages from 2013-09-21 to 2013-10-28. Participants: Keshav Kini, Roberto Tyley, Junio C Hamano. Thread: https://gitlist.dev/t/34993 ## Keshav Kini, 2013-09-21 22:16 Subject: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: <871u4hzusr.fsf@gmail.com> URL: https://gitlist.dev/e/871u4hzusr.fsf%40gmail.com ``` 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 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/ ``` ## Keshav Kini, 2013-09-22 02:38 Subject: Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: <87mwn5y40t.fsf@gmail.com> URL: https://gitlist.dev/e/87mwn5y40t.fsf%40gmail.com In-Reply-To: <871u4hzusr.fsf@gmail.com> ``` Keshav Kini 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 ``` ## Roberto Tyley, 2013-09-22 22:52 Subject: Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: <523F749E.5030306@gmail.com> URL: https://gitlist.dev/e/523F749E.5030306%40gmail.com In-Reply-To: <871u4hzusr.fsf@gmail.com> ``` 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 ``` ## Junio C Hamano, 2013-10-15 22:36 Subject: Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: URL: https://gitlist.dev/e/xmqqtxgib1qm.fsf%40gitster.dls.corp.google.com In-Reply-To: <523F749E.5030306@gmail.com> ``` Roberto Tyley 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? ``` ## Keshav Kini, 2013-10-15 22:43 Subject: Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: <87a9iayx2r.fsf@gmail.com> URL: https://gitlist.dev/e/87a9iayx2r.fsf%40gmail.com In-Reply-To: ``` Junio C Hamano writes: > Roberto Tyley 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 ``` ## Keshav Kini, 2013-10-28 17:16 Subject: Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output Message-ID: <8761shjoyx.fsf@gmail.com> URL: https://gitlist.dev/e/8761shjoyx.fsf%40gmail.com In-Reply-To: ``` Junio C Hamano writes: > Roberto Tyley 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 ```