minor bug in git pull --rebase

I saw some unexpected usage output today in git pull --rebase when I was on a detached head.

$ git pull --rebase origin BL/3.0
usage: git merge-base [-a|--all] <commit> <commit>...
   or: git merge-base [-a|--all] --octopus <commit>...
   or: git merge-base --independent <commit>...
   or: git merge-base --is-ancestor <commit> <commit>

    -a, --all             output all common ancestors
    --octopus             find ancestors for a single n-way merge
    --independent         list revs not reachable from others
    --is-ancestor         is the first one ancestor of the other?

 * branch            BL/3.0     -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to 99ba23a9fce5c5becb9dd86b5f76a8467286d811.
$

It occurs when using pull --rebase on a detached head. It's because git-pull doesn't expect ${current_branch} to be empty in some places, but it does check in others. It appears to have been introduced three years ago and no one seems to have complained yet. I hesitate to mention it during a release cycle, but I worry I'll forget later.

Here's a patch.

-- >8 --
Subject: [PATCH] git-pull: Avoid merge-base on detached head

git pull --rebase does some clever tricks to find the base for $upstream , but it forgets that we may not have any branch at all. As a result, git merge-base emits some usage noise in the middle of an otherwise successful rebase operation.

Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick.
---
There is another git-merge-base call which may need similar
treatment, but I have not dug deeply enough to see for sure.
 git-pull.sh | 1 +
 1 file changed, 1 insertion(+)