fatal: bad revision 'HEAD'

Hello,

I am having trouble installing Ruby on Rails plugins from github. when I run e.g. script/install plugin git://github.com/thoughtbot/ paperclip.git I get:

 > Initialized empty Git repository in /path/to/my/project/vendor/ 
plugins/paperclip/.git/
 > fatal: bad revision 'HEAD'
 > refusing to pull with rebase: your working tree is not up-to-date

I don't have any problems with git in general, but this error happens every time I try to install from github - even when it's a brand new rails app.

the github support team tells me it looks like a git issue - any suggestions would be appreciated!

thanks, Joel

On Sun, Aug 09, 2009 at 03:15:46PM -0600, Joel Mahoney wrote:

I can "git clone" that repository just fine. What is it exactly that installing a Rails plugin does with git? Can you try setting GIT_TRACE=1 in the environment and running your script to show us what git commands it is executing?

-Peff

[re-adding git@vger, since this discussion really belongs on the list]

On Tue, Aug 11, 2009 at 10:30:49AM -0600, Joel Mahoney wrote:

I was able to replicate your problem, but only if I set branch.master.rebase to "true" in my user-wide git config (i.e., ~/.gitconfig). It looks like "git pull" is not capable of handling a rebase when you have no commits yet.

I'm slightly dubious that such a configuration is sane, but probably "git pull" should handle this case anyway, as you can easily replicate it without config by doing:

  git init && git pull --rebase /any/git/repo

Patch is below.

-- >8 --
Subject: [PATCH] allow pull --rebase on branch yet to be born

When doing a "pull --rebase", we check to make sure that the index and working tree are clean. The index-clean check compares the index against HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.

In the case that we don't have a HEAD, we should just check if the index has anything in it, which we can do by comparing to the empty tree.

Signed-off-by: Jeff King <peff@peff.net>
---
Actually, this test is slightly more strict than the "index dirty" check
in git-rebase.sh itself. That test does "git diff-index HEAD", but
doesn't check the return code. It actually looks at whether it generates
output. So it would consider an index with something in it on a branch
yet-to-be-born to be clean, which is perhaps wrong.

Such a thing seems pretty unlikely in practice, though. I don't know if it is worth making the two tests the same (maybe it is worth refactoring into an index_is_clean function in git-sh-setup).

 git-pull.sh     |    8 +++++++-
 t/t5520-pull.sh |   11 +++++++++++
 2 files changed, 18 insertions(+), 1 deletions(-)

Jeff King <peff@peff.net> writes:

It does sound sick to store such a setting in $HOME/.gitconfig file, when the variable is clearly per-repository. As you wrote, you can easily trigger it with an explicit --rebase, but again, it is insane to ask "rebase" when you clearly do not have anything.

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.

Two comments.

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

 * 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

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

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?

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?

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

-Peff

Jeff King <peff@peff.net> writes:

I'll do this then.

-- >8 --
From: Jeff King <peff@peff.net>
Date: Tue, 11 Aug 2009 23:27:40 -0400
Subject: [PATCH] Subject: [PATCH] allow pull --rebase on branch yet to be born

When doing a "pull --rebase", we check to make sure that the index and working tree are clean. The index-clean check compares the index against HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.

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, and will lose the local change. Just check if $GIT_DIR/index exists and error out.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-pull.sh     |   18 +++++++++++++-----
 t/t5520-pull.sh |   11 +++++++++++
 2 files changed, 24 insertions(+), 5 deletions(-)

On Wed, Aug 12, 2009 at 03:49:56PM -0700, Junio C Hamano wrote:

Looks sane to me, but see below.

I had a brief moment where I thought this might not actually be sufficient. That is, can somebody create an unborn branch in an existing repo (e.g., because they want an alternate project root) in such a way that they have an index, but it is empty? In which case we should be actually checking for index emptiness instead of existence.

I.e., I have done in the past (but not frequently):

  git symbolic-ref HEAD refs/heads/to-be-born

in an existing repository to create a new root. But I don't think we really need to worry about that case:

  1. It is somewhat crazy and rare in the first place. Even more crazy
     and rare would be to "git pull --rebase" immediately afterwards.

  2. If you _did_ have an index, either:

     2a. You want to keep it, in which case your check is sane.

     2b. You want to start fresh, in which case your next step would be
         be "rm -f .git/index".

The only way this check would not be OK is is if you did something like:

  git symbolic-ref HEAD refs/heads/new-branch
  git ls-files | xargs git rm --cached
  git pull --rebase ...

which just seems crazy.

So I think I have convinced myself that what you have is fine, but I just wanted a sanity check.

-Peff

Jeff King <peff@peff.net> writes:

I honestly do not know of a sane reason (other than "because I can") anybody would want to _start_ a new root in a repository with an existing history. And doing a "pull" with or without --rebase immediately after starting a new root is doubly insane, as you say.

I do not think _ending up to_ have more than one root in your repository is necessarily insane. You may find a related project that earlier started independently but later turned out to be better off managed together with your project, and at that point you may perform Linus's "coolest merge ever" to bind the two histories together, resulting in a history with more than one root.

But that is the kind of "ending up to have" I am talking about; it is not something you _aim to_ create on purpose. If you want to _start_ a separate history, and if you are sane, you would start the separate history in a separate repository.

On Wed, Aug 12, 2009 at 09:36:04PM -0700, Junio C Hamano wrote:

IIRC, the reason I did it was to throw away history, starting a new root at the current state. Which is at least a little bit sane, though I think I might just do it with a graft and filter-branch these days.

Agreed. Let's not worry about it, then.

-Peff

Hello,

I'm not sure I completely understand where you guys are at with this thread : - ) but I thought I would mention that the question arose from my inability to install a plugin into a Ruby on Rails project based on my having (unknowingly) set branch.master.rebase = true.

I bring this up because a lot of people are getting their first exposure to git through Rails/github, and installing plugins in Rails is (I think) a good example of brining an existing history (the plugin) into a separate repository (your project). and because this maneuver is built into the "./script/plugin install" action, it is not something that cannot be easily customized.

again, I may be a little off track here, but I thought I would remind you of the original context for what that is worth : - )

thanks again for your help!

Joel

On Aug 12, 2009, at 10:38 PM, Jeff King wrote:

On Wed, Aug 12, 2009 at 11:02:45PM -0600, Joel Mahoney wrote:

Yes, the discussion moved away bit from your original issue. To summarize what is happening:

  - Setting branch.master.rebase in your ~/.gitconfig is probably not a
    good idea, as that tends to be a per-repository property, anyway.
    You can work around the problem for now by removing it.

  - Junio has committed a patch to fix the bug. It will definitely be in
    v1.6.5. If this is a common setup for Rails people, maybe we should
    consider putting it into 'maint' for v1.6.4.1.

-Peff