Re: fatal: bad revision 'HEAD'

[Jeff King <peff@peff.net>]

[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:

> here's what I get now:
> 
> trace: built-in: git 'init'
> Initialized empty Git repository in /path/to/project/vendor/plugins/
> paperclip/.git/
> trace: exec: 'git-pull' '--depth' '1' 'git://github.com/thoughtbot/
> paperclip.git'
> trace: built-in: git 'rev-parse' '--git-dir'
> trace: built-in: git 'rev-parse' '--is-inside-work-tree'
> trace: built-in: git 'rev-parse' '--show-cdup'
> trace: built-in: git 'ls-files' '-u'
> trace: built-in: git 'symbolic-ref' '-q' 'HEAD'
> trace: built-in: git 'config' '--bool' 'branch.master.rebase'
> trace: built-in: git 'update-index' '--ignore-submodules' '--refresh'
> trace: built-in: git 'diff-files' '--ignore-submodules' '--quiet'
> trace: built-in: git 'diff-index' '--ignore-submodules' '--cached'
> '--quiet' 'HEAD' '--'
> fatal: bad revision 'HEAD'
> refusing to pull with rebase: your working tree is not up-to-date

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(-)

diff --git a/git-pull.sh b/git-pull.sh
index 0f24182..427b5c6 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -119,9 +119,15 @@ error_on_no_merge_candidates () {
 }
 
 test true = "$rebase" && {
+	if git rev-parse -q --verify HEAD >/dev/null; then
+		parent_tree=HEAD
+	else # empty tree
+		parent_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904
+	fi
+
 	git update-index --ignore-submodules --refresh &&
 	git diff-files --ignore-submodules --quiet &&
-	git diff-index --ignore-submodules --cached --quiet HEAD -- ||
+	git diff-index --ignore-submodules --cached --quiet $parent_tree -- ||
 	die "refusing to pull with rebase: your working tree is not up-to-date"
 
 	oldremoteref= &&
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index e78d402..dd2ee84 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -149,4 +149,15 @@ test_expect_success 'pull --rebase dies early with dirty working directory' '
 
 '
 
+test_expect_success 'pull --rebase works on branch yet to be born' '
+	git rev-parse master >expect &&
+	mkdir empty_repo &&
+	(cd empty_repo &&
+	 git init &&
+	 git pull --rebase .. master &&
+	 git rev-parse HEAD >../actual
+	) &&
+	test_cmp expect actual
+'
+
 test_done
-- 
1.6.4.228.g9ab2.dirty