with git-next, git pull --rebase can print out "fatal: No such ref: ''" for branches without an upstream

With git-next, where git pull --rebase can print out "fatal: No such ref: ''" if git pull --rebase is run on branches without an upstream.

With git at b139ac2589b15d55cd9fa5c6957da44b150d0737, the following commands demonstrate the problem:

git init repo1
cd repo1
touch a; git add a; git commit -m "a"
cd ..
git clone repo1 repo2
cd repo2
git config remote.origin.fetch refs/heads/master:refs/remotes/origin/master git checkout -b test
git pull --rebase

This results in the following output:

fatal: No such ref: ''
Current branch test is up to date.

So the pull --rebase looks like it works, but it prints out a spurious fatal error.

I've managed to bisect this down to https://github.com/gitster/git/commit/48059e405028ebf8a09c5a9aede89dfb460cce98. Looks like get_remote_merge_branch is called without arguments, and it returns an empty string. This string is passed as-is to git merge-base, which causes the error.

This is already fixed in bb3f458 (rebase: fix fork-point with zero arguments, 2014-01-09), I think.

-Peff

If I'm reading the patch correctly, that only fixes it for git rebase, not for git pull --rebase. git-pull.sh contains a separate invocation of git merge-base --fork-point.

I'm pretty sure the invocation in git-pull.sh is OK. The error then comes out of git-rebase.sh when git-pull invokes it.

Are you running a version of git-next that includes bb3f458?

That doesn't square with 48059e4 being the culprit commit.

Yes, I am.

Doesn't the call to get_remote_merge_branch in this part

        test -n "$curr_branch" &&
        . git-parse-remote &&
        remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
        oldremoteref=$(git merge-base --fork-point "$remoteref" $curr_branch)

yield an empty string, feeding it to "merge-base --fork-point" as its first parameter?

Perhaps something like this is needed?

 git-pull.sh | 1 +
 1 file changed, 1 insertion(+)

index 605e957..467c66c 100755
@@ -229,6 +229,7 @@ test true = "$rebase" && {
 	test -n "$curr_branch" &&
 	. git-parse-remote &&
 	remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
+	test -n "$remoteref" &&
 	oldremoteref=$(git merge-base --fork-point "$remoteref" $curr_branch)
 }
 orig_head=$(git rev-parse -q --verify HEAD)

For some reason I assumed that get_remote_merge_branch would either yield a non-empty string or return failure, meaning that the &&-chain makes everything OK.

Before the change to use "merge-base --fork-point", the code was:

	oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
	for reflog in $(git rev-list -g $remoteref 2>/dev/null)
	do
		if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
		then
			oldremoteref="$reflog"
			break
		fi
	done

which has a similar failure - rev-list requires a revision argument and prints its usage if not given one.

Commit 48059e4 (pull: use merge-base --fork-point when appropriate, 2013-12-08) incorrectly assumes that get_remote_merge_branch will either yield a non-empty string or return an error, but there are circumstances where it will yield an empty string.

The previous code then invoked git-rev-list with no arguments, which results in an error suppressed by redirecting stderr to /dev/null. Now we invoke git-merge-base with an empty branch name, which also results in an error. Suppress this in the same way.

---
 git-pull.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index f210d0a..0a5aa2c 100755
@@ -229,7 +229,7 @@ test true = "$rebase" && {
 	test -n "$curr_branch" &&
 	. git-parse-remote &&
 	remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
-	oldremoteref=$(git merge-base --fork-point "$remoteref" $curr_branch)
+	oldremoteref=$(git merge-base --fork-point "$remoteref" $curr_branch 2>/dev/null)
 }
 orig_head=$(git rev-parse -q --verify HEAD)
 git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1

1.8.5.226.g0d60d77

Ah, that makes sense. I see you already followed-up with a patch, so I'll pick it up.

Thanks.