From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Thu, 30 May 2013 05:51:12 GMT
Subject: Re: [PATCH v2 4/7] add tests for rebasing root
Message-ID: <CANiSa6hMcBVcpqwbvQkCBq=fnVhUv+Va8Q_5XFQ1bjFEHERh5A@mail.gmail.com>
In-Reply-To: <51A5AECF.6070702@viscovery.net>

On Wed, May 29, 2013 at 12:31 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
>> +test_run_rebase () {
>> +     result=$1
>> +     shift
>> +     test_expect_$result "rebase $* --onto --root with merge-base does not go to root" "
>> +             reset_rebase &&
>> +             git rebase $* --onto m --root g &&
>> +             test_cmp_rev m HEAD~2 &&
>> +             test_linear_range 'c g' m..
>
> Here you check the outcome. There is no explicit check whether the rebase
> attempted to replay a and b. But that check is implicit: If a or b were
> attempted to replay, the rebase would have been interrupted with "no new
> changes". Right?

Because 'm' is a reverted 'b', I think if it had gone to the root, we
would have seen 'b m c g' (I _think_ 'a' would be silently skipped at
least in am mode).

>> +test_run_rebase failure -p
>
> Just curious: Does the last one fail because the result is not correct or
> because it does go to the root?

Because the result is not correct; it first checks out 'm', but
something goes wrong (maybe because 'm' gets written to
/rewritten/root?) and it somehow fast-forwards to 'c' (from 'b'?).