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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).