Ramkumar Ramachandra artag...@gmail.com writes:
The following command
$ git checkout -
does not work as expected after a 'git rebase -i'.
Add a failing test documenting this bug.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t2012-checkout-last.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index b44de9d..5729487 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -116,4 +116,12 @@ test_expect_success 'master...' '
test z$(git rev-parse --verify HEAD) = z$(git rev-parse --verify
master^)
'
+test_expect_failure 'checkout - works after an interactive rebase' '
+ git checkout master
+ git checkout other
+ git rebase -i master
+ git checkout -
+ test z$(git symbolic-ref HEAD) = zrefs/heads/master
+'
Hmph, you were on other and then ran rebase -i to rebase it.
When you are done, you are on other. You want to go back to the
one before you checked out the branch you started your rebase -i
on, which is master.
OK, the expectation makes sense to me.
These four are all valid ways to spell the rebase -i master step.
git rebase -i master
git rebase -i --onto master master
git rebase -i master other
git rebase -i --onto master master other
and I think it is sensible to expect
(1) they all behave the same way; or
(2) the first two behave the same, but the latter two explicitly
checks out 'other' by giving the last argument. If you are not
on 'other' when you run the rebase -i, checkout - should
come back to the branch before 'other', i.e. the branch you
started your rebase -i on.
In other words, (2) would mean:
git checkout master
git checkout -b naster
git rebase -i master other
# ends up on other
test_string_equal $(git symbolic-ref HEAD) refs/heads/other
git checkout -
# we were on naster before we rebased 'other'
test_string_equal $(git symbolic-ref HEAD) refs/heads/naster
It is a bit unclear what the following should expect.
git checkout master
git checkout other
git rebase -i master other
# ends up on other
test_string_equal $(git symbolic-ref HEAD) refs/heads/other
git checkout -
# we are on ??? before we rebased other
test_string_equal $(git symbolic-ref HEAD) refs/heads/???
One could argue that the first checkout other and then rebase done
by rebase becomes a no-op and the user should be aware of that
because rebase is started while on that other branch, in which case
we should come back to 'master'. From consistency point of view,
one could instead argue that we were on 'other' before we rebased
it, in which case it may not be unreasonable for checkout - to
come back to 'other'. I tend to prefer the former (i.e. go back to
'master') over the latter but not by a large margin.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
