Re: [BUG?] HEAD detached at HEAD
... in addition to my previous reply, looking at more context: >> --- a/wt-status.c >> +++ b/wt-status.c >> @@ -1319,6 +1319,13 @@ static int grab_1st_switch(unsigned char *osha1, >> unsigned char *nsha1, >> hashcpy(cb->nsha1, nsha1); >> for (end = target; *end && *end != '\n'; end++) >> ; >> + if (!memcmp(target, "HEAD", end - target)) { >> + /* Don't say "HEAD detached at HEAD" */ >> + unsigned char head[GIT_SHA1_RAWSZ]; >> + get_sha1("HEAD", head); >> + strbuf_addstr(>buf, find_unique_abbrev(head, >> DEFAULT_ABBREV)); >> + return 1; >> + } >> strbuf_add(>buf, target, end - target); >> return 1; >> } >> >> What do you think? I think we should return (the hex repr. of) nsha1 instead of resolving HEAD at its current state. That should solve the present problem (and leave the more difficult reflog issue for the future). Michael -- 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?] HEAD detached at HEAD
Michael J Gruberwrites: > ... in addition to my previous reply, looking at more context: > >>> --- a/wt-status.c >>> +++ b/wt-status.c >>> @@ -1319,6 +1319,13 @@ static int grab_1st_switch(unsigned char *osha1, >>> unsigned char *nsha1, >>> hashcpy(cb->nsha1, nsha1); >>> for (end = target; *end && *end != '\n'; end++) >>> ; >>> + if (!memcmp(target, "HEAD", end - target)) { >>> + /* Don't say "HEAD detached at HEAD" */ >>> + unsigned char head[GIT_SHA1_RAWSZ]; >>> + get_sha1("HEAD", head); >>> + strbuf_addstr(>buf, find_unique_abbrev(head, >>> DEFAULT_ABBREV)); >>> + return 1; >>> + } >>> strbuf_add(>buf, target, end - target); >>> return 1; >>> } >>> >>> What do you think? > > I think we should return (the hex repr. of) nsha1 instead of resolving > HEAD at its current state. That should solve the present problem (and > leave the more difficult reflog issue for the future). Indeed, resolving HEAD to its current state is wrong. I'll submit a proper patch soon. Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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?] HEAD detached at HEAD
Matthieu Moy venit, vidit, dixit 18.09.2015 21:09: > Stefan Bellerwrites: > >> On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy >> wrote: >>> Jacob Keller writes: >>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy wrote: > I'm getting it even if there's a tag and/or a branch pointing to the > same commit. > > Any idea what's going on? Any chance you accidentally made a branch or tag named HEAD? >>> >>> Nice try ;-), but no: >> >> I was playing around with origin/master and origin/pu and >> I cannot reproduce this bug. > > I investigated a bit more. The root of the problem is "git checkout > --detach" and the reflog. Here's a reproduction script: > > > rm -fr test-repo > git init test-repo > cd test-repo > echo foo>bar; git add bar; git commit -m "foo" > echo boz>bar; git add bar; git commit -m "boz" > git checkout --detach > git status > git branch > rm -fr .git/logs/ > git status > git branch > > The end of the output is: > > + git checkout --detach > + git status > HEAD detached at HEAD > nothing to commit, working directory clean > + git branch > * (HEAD detached at HEAD) > master > + rm -fr .git/logs/ > + git status > Not currently on any branch. > nothing to commit, working directory clean > + git branch > * (no branch) > master > > If one replaces "git checkout --detach" with "git checkout HEAD^0", then > the output is the one I expected: > > HEAD detached at cb39b20 > > The guilty line in the reflog is: > > checkout: moving from master to HEAD > > One possible fix is to resolve HEAD when encountering it in the reflog, > like this: > > --- a/wt-status.c > +++ b/wt-status.c > @@ -1319,6 +1319,13 @@ static int grab_1st_switch(unsigned char *osha1, > unsigned char *nsha1, > hashcpy(cb->nsha1, nsha1); > for (end = target; *end && *end != '\n'; end++) > ; > + if (!memcmp(target, "HEAD", end - target)) { > + /* Don't say "HEAD detached at HEAD" */ > + unsigned char head[GIT_SHA1_RAWSZ]; > + get_sha1("HEAD", head); > + strbuf_addstr(>buf, find_unique_abbrev(head, > DEFAULT_ABBREV)); > + return 1; > + } > strbuf_add(>buf, target, end - target); > return 1; > } > > What do you think? > > Shall I turn this into a proper patch? > > Thanks, > Thanks for finding the root cause. I think, though, that the reflog is wrong: "git checkout --detach" should be equivalent to "git checkout HEAD^0", shouldn't it? It becomes clearer with branches: git co --detach master git reflog 3b9153c HEAD@{0}: checkout: moving from master to master I think that information ("moving ... to master") is misleading at best, if not wrong (depending on how you read the reflog). In any case you cannot distinguish a regular branch checkout (i.e. branch switching) from a "--detach" checkout in the reflog, which is bad. The same happens when you "git checkout origin/next" and you get --detach kicking in automatically. It looks like a regular branch checkout. So, maybe we should really fix the reflog, e.g. by amending the information there? status/branch figure out that they're in the detached case even without the help from reflog, and your patch is correct as long as we don't commit on top of the fork point. But as soon as we do that, resolving "HEAD" will not give you the fork point, and the output of "detached from..." will be incorrect (based on my reading of the patch and my memory of the workings, no compile test yet, sorry). Michael -- 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?] HEAD detached at HEAD
Matthieu Moywrites: > I investigated a bit more. The root of the problem is "git checkout > --detach" and the reflog. Here's a reproduction script: > ... > If one replaces "git checkout --detach" with "git checkout HEAD^0", then > the output is the one I expected: > > HEAD detached at cb39b20 > > The guilty line in the reflog is: > > checkout: moving from master to HEAD Yeah, that sounds broken. --detach should write the same reflog entry as "git checkout HEAD^0". -- 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?] HEAD detached at HEAD
Stefan Bellerwrites: > On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy > wrote: >> Jacob Keller writes: >> >>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy >>> wrote: I'm getting it even if there's a tag and/or a branch pointing to the same commit. Any idea what's going on? >>> >>> Any chance you accidentally made a branch or tag named HEAD? >> >> Nice try ;-), but no: > > I was playing around with origin/master and origin/pu and > I cannot reproduce this bug. I investigated a bit more. The root of the problem is "git checkout --detach" and the reflog. Here's a reproduction script: rm -fr test-repo git init test-repo cd test-repo echo foo>bar; git add bar; git commit -m "foo" echo boz>bar; git add bar; git commit -m "boz" git checkout --detach git status git branch rm -fr .git/logs/ git status git branch The end of the output is: + git checkout --detach + git status HEAD detached at HEAD nothing to commit, working directory clean + git branch * (HEAD detached at HEAD) master + rm -fr .git/logs/ + git status Not currently on any branch. nothing to commit, working directory clean + git branch * (no branch) master If one replaces "git checkout --detach" with "git checkout HEAD^0", then the output is the one I expected: HEAD detached at cb39b20 The guilty line in the reflog is: checkout: moving from master to HEAD One possible fix is to resolve HEAD when encountering it in the reflog, like this: --- a/wt-status.c +++ b/wt-status.c @@ -1319,6 +1319,13 @@ static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1, hashcpy(cb->nsha1, nsha1); for (end = target; *end && *end != '\n'; end++) ; + if (!memcmp(target, "HEAD", end - target)) { + /* Don't say "HEAD detached at HEAD" */ + unsigned char head[GIT_SHA1_RAWSZ]; + get_sha1("HEAD", head); + strbuf_addstr(>buf, find_unique_abbrev(head, DEFAULT_ABBREV)); + return 1; + } strbuf_add(>buf, target, end - target); return 1; } What do you think? Shall I turn this into a proper patch? Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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?] HEAD detached at HEAD
Hi, I did a "git checkout --detached", and now I get: $ git status HEAD detached at HEAD nothing to commit, working directory clean $ git branch * (HEAD detached at HEAD) master The "HEAD detached at HEAD" is not very helpful. I thought there was an abbreved sha1 here before, but I'm getting the same with latest Git in master and Git 2.0, so it doesn't seem to be new. I'm getting it even if there's a tag and/or a branch pointing to the same commit. Any idea what's going on? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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?] HEAD detached at HEAD
On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moywrote: > I'm getting it even if there's a tag and/or a branch pointing to the > same commit. > > Any idea what's going on? > Any chance you accidentally made a branch or tag named HEAD? Regards, Jake -- 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?] HEAD detached at HEAD
Jacob Kellerwrites: > On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy > wrote: >> I'm getting it even if there's a tag and/or a branch pointing to the >> same commit. >> >> Any idea what's going on? > > Any chance you accidentally made a branch or tag named HEAD? Nice try ;-), but no: $ git status HEAD detached at HEAD nothing to commit, working directory clean $ git for-each-ref 16aa1796fb487fc7178ceef0525fed80284a4c52 commit refs/heads/master 16aa1796fb487fc7178ceef0525fed80284a4c52 commit refs/tags/foo $ git rev-parse HEAD 16aa1796fb487fc7178ceef0525fed80284a4c52 -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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?] HEAD detached at HEAD
On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moywrote: > Jacob Keller writes: > >> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy >> wrote: >>> I'm getting it even if there's a tag and/or a branch pointing to the >>> same commit. >>> >>> Any idea what's going on? >> >> Any chance you accidentally made a branch or tag named HEAD? > > Nice try ;-), but no: I was playing around with origin/master and origin/pu and I cannot reproduce this bug. However maybe Michael as the author of 4b063186 (2015-03-03 branch: name detached HEAD analogous to status) can help here ? > > $ git status > HEAD detached at HEAD > nothing to commit, working directory clean > > $ git for-each-ref > 16aa1796fb487fc7178ceef0525fed80284a4c52 commit refs/heads/master > 16aa1796fb487fc7178ceef0525fed80284a4c52 commit refs/tags/foo > > $ git rev-parse HEAD > 16aa1796fb487fc7178ceef0525fed80284a4c52 > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ > -- > 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 -- 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