git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Joel Mahoney <joelmahoney@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: fatal: bad revision 'HEAD'
Date: Wed, 12 Aug 2009 03:58:33 -0400	[thread overview]
Message-ID: <20090812075833.GF15152@coredump.intra.peff.net> (raw)
In-Reply-To: <7v7hx98otz.fsf@alter.siamese.dyndns.org>

On Wed, Aug 12, 2009 at 12:37:44AM -0700, Junio C Hamano wrote:

> But just like we twisted the definition of merge to mean "merging
> something into nothing yields that something", we could twist the
> definition of rebase to mean "rebasing nothing on top of something result
> in that something".  It sort of makes sense in a twisted way.

I dunno. It doesn't seem all that twisted to me.

But like many of the "branch to be born" and "initial commit" edge cases
we have dealt with, it is not so much about somebody intentionally
triggering this as it is about doing something sane when some script
_does_ trigger it. And I think the sane thing is obvious and easy to do
here, so why not?

>  * Is "rev-parse -q --verify" a safe test to guarantee that HEAD is
>    unborn?  Shouldn't we be checking with "symbolic-ref" or something?

I'm not sure. The test in git-checkout, for example, seems to basically
just be looking up HEAD as a commit. If it doesn't work, then the branch
is to-be-born (see switch_branches in builtin-checkout.c).

Which is more or less what's happening here (except we don't check that
the type is a commit).

With symbolic-ref, I guess we could find out what the ref is, and check
to see if _that_ exists. But I can't think of a situation where that
would be meaningfully different than just resolving HEAD. Obviously
detached HEADs come to mind, but wouldn't you then by definition not be
a branch-to-be-born, which is what this rev-parse test would tell you?

>  * In such an "unborn branch" case, by definition, a non-empty index won't
>    be based on whatever we are pulling down from the remote.  So how about
>    doing something like the following instead?
> 
> 	if on unborn branch
> 	then
> 		if test -f "$GIT_DIR/index"
>                 then
> 			die "refusing to update; you have a non-empty index"
> 		fi
> 	else
> 		... existing tests against HEAD ...
> 	fi

Yeah, I think that is a better idea. Do you want to tweak the patch, or
should I re-submit?

-Peff

  reply	other threads:[~2009-08-12  7:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-09 21:15 fatal: bad revision 'HEAD' Joel Mahoney
2009-08-10  1:18 ` Jeff King
     [not found]   ` <09EE2E57-626B-4686-A6DD-3B8DF1BC3FE2@gmail.com>
     [not found]     ` <20090811015615.GA8383@coredump.intra.peff.net>
     [not found]       ` <C44788EB-02BA-4D69-8091-9E97827223A0@gmail.com>
2009-08-12  3:27         ` Jeff King
2009-08-12  7:37           ` Junio C Hamano
2009-08-12  7:58             ` Jeff King [this message]
2009-08-12 22:49               ` Junio C Hamano
2009-08-13  2:31                 ` Jeff King
2009-08-13  4:36                   ` Junio C Hamano
2009-08-13  4:38                     ` Jeff King
2009-08-13  5:02                       ` Joel Mahoney
2009-08-13  5:10                         ` Jeff King

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=20090812075833.GF15152@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=joelmahoney@gmail.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).