From: Marc Branchaud <marcnarc@xiplink.com>
To: Junio C Hamano <gitster@pobox.com>,
Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Date: Mon, 23 Feb 2015 10:21:29 -0500 [thread overview]
Message-ID: <54EB4579.3000103@xiplink.com> (raw)
In-Reply-To: <xmqqa905wy43.fsf@gitster.dls.corp.google.com>
On 15-02-22 02:21 PM, Junio C Hamano wrote:
> 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
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.
next prev parent reply other threads:[~2015-02-23 15:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 17:38 [RFC/PATCH] branch: name detached HEAD analogous to status Michael J Gruber
2015-02-22 19:21 ` Junio C Hamano
2015-02-23 8:50 ` Michael J Gruber
2015-02-23 15:21 ` Marc Branchaud [this message]
2015-03-06 15:04 ` [PATCHv2 0/2] branch output for detached HEAD Michael J Gruber
2015-03-06 15:04 ` [PATCHv2 1/2] wt-status: refactor detached HEAD analysis Michael J Gruber
2015-03-06 15:04 ` [PATCHv2 2/2] branch: name detached HEAD analogous to status Michael J Gruber
2015-03-06 20:23 ` Junio C Hamano
2015-02-23 15:12 ` [RFC/PATCH] " Marc Branchaud
2015-02-23 16:24 ` Michael J Gruber
2015-02-23 17:23 ` Marc Branchaud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EB4579.3000103@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.