On Sun, 14 Mar 2010, Junio C Hamano wrote:
Ahh, Ok, the point is that when we start this sequence we are on a branch,
and then you want to end up on a detached HEAD that points at the result
of the branch.
Yep, you got it
I'll queue it in 'pu', but with a little tweak to the test to make it
clear what is going on, perhaps like this.
test_expect_success 'rebase while detaching HEAD' '
git symbolic-ref HEAD &&
grandparent=$(git rev-parse HEAD~2) &&
test_tick &&
FAKE_LINES="2 1" git rebase -i HEAD~2 HEAD^0 &&
test $grandparent = $(git rev-parse HEAD~2) &&
test_must_fail git symbolic-ref HEAD
'
Good idea. Thanks.
We may need to document this behaviour, by the way, if we make it official
that the extra "branch to be rewritten" parameter can be a non-branch.
Two points are that you can give arbitrary commit, and that you will end
up with a detached HEAD that points at the result if you did so.
Also I did't followed the code, but does it behave sanely when you say
"rebase --abort"?
Good question. It turns out that both rebase and rebase -i will end
up on the commit specified by <branch>, whether it's a branch or not.
That might be the expected and desired behavior, though:
[Starting on branch A]
git rebase origin/B B
git rebase --abort
[HEAD is now a symref to B]
[Starting on branch A]
git rebase origin/B B^0
git rebase --abort
[HEAD is now detached at B^0]
--
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