Matthieu Moy venit, vidit, dixit 18.09.2015 21:09:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy
>> <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
>>> Jacob Keller <jacob.keller@xxxxxxxxx> writes:
>>>
>>>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
>>>> <Matthieu.Moy@xxxxxxxxxxxxxxx> 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(&cb->buf, find_unique_abbrev(head, DEFAULT_ABBREV));
> + return 1;
> + }
> strbuf_add(&cb->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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html