From: Dave Olszewski <cxreg@pobox.com>
Date: Mon, 15 Mar 2010 08:41:30 GMT
Subject: Re: Re: [PATCH] rebase--interactive: don't enforce valid branch
Message-ID: <alpine.DEB.2.00.1003150132060.4362@narbuckle.genericorp.net>
In-Reply-To: <7vd3z6f6wt.fsf@alter.siamese.dyndns.org>

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]