[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@xxxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html