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

[Junio C Hamano <gitster@pobox.com>]

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

     $ git log ...$topic
     $ git show-branch HEAD $topic

     would be a lot more useful than having to learn "where did I
     detach" from either "status" or "branch" and then do something
     about that the abbreviated object name (like feeding it to
     "describe" or "log").

Of course, the decision to make the point the HEAD was originally
detached at is not an issue this patch introduces, but it makes me
wonder if that existing "at vs from" logic is an overall win or a
loss.