From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head
Date: Thu, 9 May 2013 08:46:07 +0200 [thread overview]
Message-ID: <20130509064607.GA11985@sigill.intra.peff.net> (raw)
In-Reply-To: <7vk3n9dvlu.fsf@alter.siamese.dyndns.org>
On Wed, May 08, 2013 at 02:12:29PM -0700, Junio C Hamano wrote:
> The original API read "checkout: moving from (.*) to ..." from the
> reflog of the HEAD, and returned the substring between "from" and
> "to", but there was no way, if the substring was a 40-hex string, to
> tell if we were on a detached HEAD at that commit object, or on a
> branch whose name happened to be the 40-hex string.
>
> At this point, we cannot afford to change the format recorded in the
> reflog, so introduce a heuristics to see if the 40-hex matches the
> object name of the commit we are switching out of. This will
> unfortunately mishandle this case:
>
> HEX=$(git rev-parse master)
> git checkout -b $HEX master
> git checkout master
I do not think I've ever seen a 40-hex branch name in practice, but I
would think a branch named after the commit tip would be a reasonably
common reason to have one, and would trigger this case.
Since the point of marking the detached HEAD is to turn off things like
"@{-1}@{u}", we would want to be generous and err on the side of
assuming it is a branch if it _might_ be one. IOW, shouldn't we treat
the above sequence as a branch, and therefore mishandle:
git checkout $HEX^0 master
git checkout master
by erroneously assuming that we moved to the branch $HEX?
-Peff
next prev parent reply other threads:[~2013-05-09 6:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 21:12 [PATCH 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head Junio C Hamano
2013-05-08 21:18 ` [PATCH 2/2] interpret_branch_name(): unconfuse @{-1}@{u} when @{-1} is detached Junio C Hamano
2013-05-08 21:32 ` [non PATCH */2] preparatory analysis of remaining @{...} issues Junio C Hamano
2013-05-09 6:46 ` Jeff King [this message]
2013-05-09 17:08 ` [PATCH 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head Junio C Hamano
2013-05-13 12:04 ` Jeff King
2013-05-09 18:24 ` Eric Sunshine
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=20130509064607.GA11985@sigill.intra.peff.net \
--to=peff@peff.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 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 NNTP newsgroup(s).