Jeff King <peff@xxxxxxxx> writes:
> 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.
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.
> 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"
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
--
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