From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
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, 09 May 2013 10:08:24 -0700 [thread overview]
Message-ID: <7vhaicaxo7.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130509064607.GA11985@sigill.intra.peff.net> (Jeff King's message of "Thu, 9 May 2013 08:46:07 +0200")
Jeff King <peff@peff.net> writes:
> 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.
I am not sure X and Y mesh well in your "Since X, we would want Y".
It seems to argue for erring on the side of detached HEAD to me.
Checking the "from" name $HEX against old_sha1 is a local and cheap
measure I added there for the first level of disambiguation. If
they do not match, we _know_ we didn't come back from a detached
HEAD state.
In order to err on the "favor branch when it could have been one",
you could additionally look for the reflog .git/logs/refs/heads/$HEX
when the "from" name $HEX matches old_sha1 (which is likely to be
detached, but it is possible that we were on the $HEX branch when
its tip was at $HEX) and making sure the tip of that $HEX branch
once used to be at $HEX at the time recorded for @{-N} in the HEAD
reflog in question.
That is far more expensive, though; I doubt it is worth doing.
next prev parent reply other threads:[~2013-05-09 17:08 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 ` [PATCH 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head Jeff King
2013-05-09 17:08 ` Junio C Hamano [this message]
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=7vhaicaxo7.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.