Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
Junio C Hamano gits...@pobox.com writes: Roberto Tyley roberto.ty...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
Roberto Tyley roberto.ty...@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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
Junio C Hamano gits...@pobox.com writes: Roberto Tyley roberto.ty...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG?] 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
00afb9f9a0c87dba4a203413358984e9f4fa5ffb Keshav Kini keshav.k...@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/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
Keshav Kini keshav.k...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
