When we 'git rebase $upstream', git uses 'rev-parse --verify
$current_branch' to find ORIG_HEAD. But if $current_branch
is ambiguous, 'rev-parse --verify' emits a warning and returns
a SHA1 anyway. When the wrong ambiguous choice is used,
git-rebase fails non-gracefully: it emits a warning about
failing to lock $current_branch, an error about being unable to
checkout $current_branch again, and it might even decide the
rebase is a fast-forward when it is not.
In the 'rebase $upstream' case, we already know the unambiguous
spelling of $current_branch is "HEAD". Fix git-rebase to find
$orig_head unambiguously.
Add a test in t3400-rebase.sh which creates an ambiguous branch
name and rebases it implicitly with 'git rebase $other'.
Signed-off-by: Phil Hord <hordp@cisco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
head_name="detached HEAD"
branch_name=HEAD ;# detached
fi
- orig_head=$(git rev-parse --verify "${branch_name}^0") || exit
+ orig_head=$(git rev-parse --verify HEAD) || exit
;;
*)
die "BUG: unexpected number of arguments left to parse"
test $(git rev-parse HEAD@{1}) != $(git rev-parse my-topic-branch@{1})
'
+test_expect_success 'rebase from ambiguous branch name' '
+ git checkout -b topic side &&
+ git rebase master
+'
+
test_expect_success 'rebase after merge master' '
+ git checkout --detach refs/tags/topic &&
+ git branch -D topic &&
git reset --hard topic &&
git merge master &&
git rebase master &&