From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: Jiang Xin <worldhello.net@gmail•com>, Git List <git@vger•kernel.org>
Subject: Re: [PATCH] receive-pack: crash when checking with non-exist HEAD
Date: Thu, 23 Jul 2015 10:49:39 -0700 [thread overview]
Message-ID: <xmqqk2tqpxvw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150723055817.GA26794@peff.net> (Jeff King's message of "Wed, 22 Jul 2015 22:58:18 -0700")
Jeff King <peff@peff•net> writes:
> On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote:
>
>> For example, in order to "git commit" from such a state to create
>> the root commit on that branch, existing unrelated branches whose
>> names collide with the branch must be removed, which would mean one
>> of two things, either (1) you end up losing many unrelated work, or
>> (2) the command refuses to work, not letting you to record the
>> commit. Neither is satisfactory, but we seem to choose (2), which
>> is at least the safer of the two:
>>
>> $ git checkout master
>> $ git checkout --orphan master/1
>> $ git commit -m foo
>> fatal: cannot lock ref 'HEAD': 'refs/heads/master' exists;
>> cannot create 'refs/heads/master/1'
>
> Yeah, that seems sensible. I think the "way out" for the user here would
> presumably be:
>
> git symbolic-ref HEAD refs/heads/something-else
>
> though of course they could also rename the other ref.
I would have expected you to say
git checkout --orphan something-else
which should work and would be more intuitive ;-)
> Right. You'd have to teach the is_refname_available() check to always
> check what HEAD points to, and consider it as "taken", even if the ref
> itself doesn't exist. But what about other symbolic refs? The
> "refs/remotes/origin/HEAD" symref may point to
> "refs/remotes/origin/master" even though "refs/remotes/origin/master/1"
> exists. I doubt that will cause real problems in practice, but it points
> out that special cases like "the value of HEAD is magic and reserved"
> will later end up being insufficient as the code is extended.
Yes, we do not have a handy cache of all symrefs, and it is dubious
if this issue is grave enough to warrant adding one.
> I think I'd be willing to simply punt on the whole thing as being too
> rare to come up in practice.
I tend to agree.
prev parent reply other threads:[~2015-07-23 17:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 1:49 [PATCH] receive-pack: crash when checking with non-exist HEAD Jiang Xin
2015-07-22 20:30 ` Junio C Hamano
2015-07-23 5:58 ` Jeff King
2015-07-23 17:49 ` Junio C Hamano [this message]
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=xmqqk2tqpxvw.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=worldhello.net@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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