On Wed, May 29, 2013 at 12:31 AM, Johannes Sixt <j.s...@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'?).
--
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
