{"thread":{"id":"34993","subject":"[BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","startedAt":"2013-09-21T22:16:01Z","lastAt":"2013-10-28T17:16:06Z","messageCount":6,"participants":["Keshav Kini","Roberto Tyley","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"228016","messageId":"871u4hzusr.fsf@gmail.com","threadId":"34993","inReplyTo":null,"subject":"[BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Keshav Kini","fromEmail":"keshav.kini@gmail.com","sentAt":"2013-09-21T22:16:01Z","receivedAt":"2013-09-21T22:16:01Z","isPatch":false,"sender":{"key":"keshav.kini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/691290?v=4"},"body":"Hello,\n\nWhen trying out Roberto Tyley's BFG Repo-Cleaner program [1], I managed\nto put a git repository in the following state:\n\n [2] fs@erdos /tmp/bfg-test-repo $ cat .git/logs/HEAD\n 0000000000000000000000000000000000000000 00afb9f9a0c87dba4a203413358984e9f4fa5ffb Keshav Kini 1379746570 -0500\tclone: from /home/fs/work/x86\n [2] fs@erdos /tmp/bfg-test-repo $ git rev-parse HEAD\n a29caa4646698bcf2273cc60d3d612593b4ced8f\n [2] fs@erdos /tmp/bfg-test-repo $ git reflog | cat\n 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\n [2] fs@erdos /tmp/bfg-test-repo $ git fsck\n Checking object directories: 100% (256/256), done.\n Checking objects: 100% (6635/6635), done.\n [2] fs@erdos /tmp/bfg-test-repo $ echo $?\n 0\n\nThis situation came about because the BFG Repo-Cleaner doesn't write new\nreflog entries after creating its new objects and moving refs around.\nBut that aside, I think how git handles the situation might be a bug.\n\nAs you can see, HEAD is currently at a29caa46, but the reflog's data\nfile .git/logs/HEAD doesn't describe how it came to be at a29caa46. The\nsingle reflog entry describes how the HEAD pointer was initialized to\n00afb9f9 when I cloned the repository from /home/fs/work/x86 .\n\nBy the wording of the `git reflog` man page, I would assume that the\nlines displayed by `git reflog show HEAD` would correspond to a chain of\nreflog entries, where the short commit ID at the beginning of each line\nwould represent the second field of the reflog entry in question, and\nthe first field of the reflog entry would correspond to the short commit\nID at the beginning of the line directly below. For example, if `git\nreflog show HEAD` displayed this:\n\n 0123456 [stuff] foo\n 789abcd [stuff] bar\n ef01234 [stuff] baz\n\nThen I would expect the reflog data file for HEAD to look something like\nthis, where '.' represents an unknown hex digit:\n\n 789abcd................................. 0123456................................. [stuff]\n ef01234................................. 789abcd................................. [stuff]\n ........................................ ef01234................................. [stuff]\n\nHowever, in this example, the short commit ID shown in `git reflog show`\ndoesn't even appear in the reflog data file!\n\nIt seems to me that one of two things should be the case. Either 1) it\nshould be considered impossible to have a reflog for a ref X which\ndoesn't contain a chain of commits leading up to the current location of\nX; or 2) if reflogs are allowed not to form an unbroken chain of commits\nleading to X, then `git reflog show` should at least make sure to\nactually display a commit ID corresponding to the second field of each\nreflog entry it reads, and not some other commit ID.\n\nIn the first case, the bug is that `git fsck` doesn't catch the\nsupposedly impossible situation that exists in the repository I've\ndescribed in this email. In the second case, the bug is that `git reflog\nshow` has bad output.\n\nI'm reporting this because I was having difficulty figuring out why `git\ngc` was not collecting the commit 00afb9f. The reason turned out to be\nthat it was mentioned in a reflog and thus not getting pruned, which\nwould have been much easier to discover had the output of `git reflog\nshow` mentioned 00afb9f at all.\n\nPlease let me know what you think.\n\nThanks,\n Keshav\n\n\n[1] http://rtyley.github.io/bfg-repo-cleaner/\n"},{"id":"228023","messageId":"87mwn5y40t.fsf@gmail.com","threadId":"34993","inReplyTo":"871u4hzusr.fsf@gmail.com","subject":"Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Keshav Kini","fromEmail":"keshav.kini@gmail.com","sentAt":"2013-09-22T02:38:26Z","receivedAt":"2013-09-22T02:38:26Z","isPatch":false,"sender":{"key":"keshav.kini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/691290?v=4"},"body":"Keshav Kini writes:\n> For example, if `git\n> reflog show HEAD` displayed this:\n>\n> 0123456 [stuff] foo\n> 789abcd [stuff] bar\n> ef01234 [stuff] baz\n>\n> Then I would expect the reflog data file for HEAD to look something like\n> this, where '.' represents an unknown hex digit:\n>\n> 789abcd................................. 0123456................................. [stuff]\n> ef01234................................. 789abcd................................. [stuff]\n> ........................................ ef01234................................. [stuff]\n\nSorry, that's backwards -- I would actually expect this:\n\n ........................................ ef01234................................. [stuff]\n ef01234................................. 789abcd................................. [stuff]\n 789abcd................................. 0123456................................. [stuff]\n\n-Keshav\n"},{"id":"228039","messageId":"523F749E.5030306@gmail.com","threadId":"34993","inReplyTo":"871u4hzusr.fsf@gmail.com","subject":"Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Roberto Tyley","fromEmail":"roberto.tyley@gmail.com","sentAt":"2013-09-22T22:52:14Z","receivedAt":"2013-09-22T22:52:14Z","isPatch":false,"sender":{"key":"roberto.tyley@gmail.com","avatar":"https://avatars.githubusercontent.com/u/52038?v=4"},"body":"On 21/09/2013 23:16, Keshav Kini wrote:\n> [SNIP]\n> This situation came about because the BFG Repo-Cleaner doesn't write new\n> reflog entries after creating its new objects and moving refs around.\n\nTrue enough - I don't think the BFG does write new entires to the\nreflog when it does the final ref-update, and it would be nicer if it \ndid. I'll get that fixed.\n\nthanks,\nRoberto\n"},{"id":"229033","messageId":"xmqqtxgib1qm.fsf@gitster.dls.corp.google.com","threadId":"34993","inReplyTo":"523F749E.5030306@gmail.com","subject":"Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-15T22:36:33Z","receivedAt":"2013-10-15T22:36:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Roberto Tyley writes:\n\n> On 21/09/2013 23:16, Keshav Kini wrote:\n>> [SNIP]\n>> This situation came about because the BFG Repo-Cleaner doesn't write new\n>> reflog entries after creating its new objects and moving refs around.\n>\n> True enough - I don't think the BFG does write new entires to the\n> reflog when it does the final ref-update, and it would be nicer if it\n> did. I'll get that fixed.\n\n(sorry for replying late)\n\nSo this can be closed as \"BFG not writing reflog in a consistent\nway, and 'git reflog show' is acting GIGO way\"? Or was there\nsomething the core side needs to do?\n"},{"id":"229035","messageId":"87a9iayx2r.fsf@gmail.com","threadId":"34993","inReplyTo":"xmqqtxgib1qm.fsf@gitster.dls.corp.google.com","subject":"Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Keshav Kini","fromEmail":"keshav.kini@gmail.com","sentAt":"2013-10-15T22:43:24Z","receivedAt":"2013-10-15T22:43:24Z","isPatch":false,"sender":{"key":"keshav.kini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/691290?v=4"},"body":"Junio C Hamano writes:\n\n> Roberto Tyley writes:\n>\n>> On 21/09/2013 23:16, Keshav Kini wrote:\n>>> [SNIP]\n>>> This situation came about because the BFG Repo-Cleaner doesn't write new\n>>> reflog entries after creating its new objects and moving refs around.\n>>\n>> True enough - I don't think the BFG does write new entires to the\n>> reflog when it does the final ref-update, and it would be nicer if it\n>> did. I'll get that fixed.\n>\n> (sorry for replying late)\n>\n> So this can be closed as \"BFG not writing reflog in a consistent\n> way, and 'git reflog show' is acting GIGO way\"? Or was there\n> something the core side needs to do?\n\nHi Junio,\n\nThanks for your reply. In my original mail, immediately after the\nsnippet Roberto quoted above, I said, \"But that aside, I think how git\nhandles the situation might be a bug.\" To wit:\n\n> It seems to me that one of two things should be the case. Either 1) it\n> should be considered impossible to have a reflog for a ref X which\n> doesn't contain a chain of commits leading up to the current location of\n> X; or 2) if reflogs are allowed not to form an unbroken chain of commits\n> leading to X, then `git reflog show` should at least make sure to\n> actually display a commit ID corresponding to the second field of each\n> reflog entry it reads, and not some other commit ID.\n> \n> In the first case, the bug is that `git fsck` doesn't catch the\n> supposedly impossible situation that exists in the repository I've\n> described in this email. In the second case, the bug is that `git reflog\n> show` has bad output.\n\nBefore this is closed, I would appreciate it if I could get some\nfeedback from git developers on the above two paragraphs.\n\nThanks,\n Keshav\n"},{"id":"229650","messageId":"8761shjoyx.fsf@gmail.com","threadId":"34993","inReplyTo":"xmqqtxgib1qm.fsf@gitster.dls.corp.google.com","subject":"Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output","fromName":"Keshav Kini","fromEmail":"keshav.kini@gmail.com","sentAt":"2013-10-28T17:16:06Z","receivedAt":"2013-10-28T17:16:06Z","isPatch":false,"sender":{"key":"keshav.kini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/691290?v=4"},"body":"Junio C Hamano writes:\n> Roberto Tyley writes:\n>> On 21/09/2013 23:16, Keshav Kini wrote:\n>>> [SNIP]\n>>> This situation came about because the BFG Repo-Cleaner doesn't write new\n>>> reflog entries after creating its new objects and moving refs around.\n>>\n>> True enough - I don't think the BFG does write new entires to the\n>> reflog when it does the final ref-update, and it would be nicer if it\n>> did. I'll get that fixed.\n>\n> (sorry for replying late)\n>\n> So this can be closed as \"BFG not writing reflog in a consistent\n> way, and 'git reflog show' is acting GIGO way\"? Or was there\n> something the core side needs to do?\n\nHi Junio,\n\nBelow I'm resending a mail that I sent to the list earlier, but not to\nyou or Roberto personally, as I just realized. So in case you didn't\nsee it before, here it is -- if you did see it before, sorry for the\nnoise.\n\n\n\nHi Junio,\n\nThanks for your reply. In my original mail, immediately after the\nsnippet Roberto quoted above, I said, \"But that aside, I think how git\nhandles the situation might be a bug.\" To wit:\n\n> It seems to me that one of two things should be the case. Either 1) it\n> should be considered impossible to have a reflog for a ref X which\n> doesn't contain a chain of commits leading up to the current location of\n> X; or 2) if reflogs are allowed not to form an unbroken chain of commits\n> leading to X, then `git reflog show` should at least make sure to\n> actually display a commit ID corresponding to the second field of each\n> reflog entry it reads, and not some other commit ID.\n> \n> In the first case, the bug is that `git fsck` doesn't catch the\n> supposedly impossible situation that exists in the repository I've\n> described in this email. In the second case, the bug is that `git reflog\n> show` has bad output.\n\nBefore this is closed, I would appreciate it if I could get some\nfeedback from git developers on the above two paragraphs.\n\nThanks,\n Keshav\n"}]}