On 15-02-22 02:21 PM, Junio C Hamano wrote:
> 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
I find it very useful, because I often work on HEADs detached from remote
branches ("git checkout origin/foo"). If I'm sight-seeing, I like the
reminder of which remote branch I checked out, especially because I often
have several working tress going at the same time. I also often make trivial
changes, like typo fixes, on such detached HEADs, and here too I appreciate
the reminder of which remote branch I should push HEAD to.
M.
--
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
