Michael J Gruber <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
