Junio C Hamano <gitster@xxxxxxxxx> writes:
> Dave Olszewski <cxreg@xxxxxxxxx> writes:
>
>>>> +test_expect_success 'rebase while detaching HEAD' '
>>>> + grandparent=$(git rev-parse HEAD~2) &&
>>>> + test_tick &&
>>>> + FAKE_LINES="2 1" git rebase -i HEAD~2 HEAD^0 &&
>>>
>>> What's the point of saying this? You could instead say:
>>>
>>> git rebase -i HEAD~2
>>>
>>> no?
>> ...
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.
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
'
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"?
--
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