Re: [RFC/PATCH] branch: name detached HEAD analogous to status

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> "git status" carefully names a detached HEAD "at" resp. "from" a rev or
>> ref depending on whether the detached HEAD has moved since. "git branch"
>> always uses "from", which can be confusing, because a status-aware user
>> would interpret this as moved detached HEAD.
>>
>> Make "git branch" use the same logic and wording.
> 
> Yeah, otherwise the user would wonder why sometimes the object name
> after that "from" matches "git rev-parse HEAD" and sometimes does
> not.
> 
> In order to make sure that it will be easy for us to maintain that
> these two commands will keep using the same logic and wording after
> this "fix" is applied, should this patch do a bit more?  Or is it
> worth doing that for such a small piece of code to be shared?
> 
> The following is a tangent and I do not think it is likely we would
> do anything about it, but I wonder what value we give the end users
> by showing the "from" information, both in "status" and "branch" in
> the first place.  When I am on a detached HEAD, I'd be doing one of
> these three things:
> 
>  (1) I am on some kind of sequencing machinery (e.g. "rebase -i",
>      "cherry-pick A..B", or "bisect").  It does not matter to me at
>      all if I am at the same commit at which I started the sequenced
>      operations or the sequencing machinery has moved me one or more
>      commits along its planned course of action, or where the
>      original point the sequencing machinery detached the HEAD at.
>      I suspect that I would not use "git status" or "git branch" in
>      this mode anyway.
> 
>  (2) I am sight-seeing, starting with e.g. "git checkout v2.0.0",
>      and moving around with "git checkout $some_other_commit".  I'd
>      always see that I am "at" the commit I last checked out, so the
>      distinctions would not be even shown to me.
> 
>  (3) I am experimenting to fix or enhance an existing thing that is
>      meant to eventually hit a concrete branch, but I do not know if
>      the experiment would pan out. "git checkout $topic~$n" would be
>      to start from near the tip of that $topic ($n may often be 0
>      but not always) and then I would "git commit" my experiments.
>      When I assess my progress, I'd be interested in what I have
>      that is not in $topic and vice versa since I started that
>      experiment, so