[darcs-devel] [patch1902] add failing test for rebase of conflicted patches

[Ganesh Sittampalam]

Ganesh Sittampalam <ganesh at earth.li> added the comment:

> What remains to show is that this is
> actually equivalent to your optimized implementation. What means
> "equivalent"? I think we agree that here it can only mean equal up to
> commutation and cancellation of inverses.

FWIW I don't have an optimized implementation yet, just some quick
hacks. What I've done needs to at least be changed to find all pairs of
inverses in the adjacent fixups.

> What about the general case where P and thus P' may consist of several
> patches? I think this is a simple consequence of permutivity: in P' =
> p1';...;pn' the pi' are adjacent, so for the corresponding
> P=f1;p1;g1;...;fn;pn;gn (with gi the fixups after pi), it must be
> possible to find a commutation where the p1;...;pn are also adjacent.

I don't think permutivity applies here. The sequence f1;p1;g1;... was
never reached by commuting p1';...;pn' (at least not at the Prim level).
Just because p;q are adjacent, doesn't mean you can commute p;r;r^;q to
get p;q if r is something that has a dependency (e.g. if it just deletes
the whole repo).

>> So far what I have is in the Unwind instance for FL, but it's pretty
>> hacky and I really don't want it to depend on coalesce/canonize;
> 
> No it should definitely not. I think a good point of reference is the
> code for commutePast in Dracs.Patch.V3.Contexted.

Did you mean ctxAdd? commutePast on its own doesn't cancel inverses.

>>> That is, ToEdit will have to consist of a PatchInfo plus explicit
>>> dependencies, plus a /sequence/ of (fixup;patch), not just a single one.
>>
>>> This could be done by embedding a Named (RebasePatch prim), where
>>> (RebasePatch prim) lives at the same level as (RepoPatchVx prim) and
>>> consists of (fixups;prim) or perhaps even (fixups;prim;fixups). The
>>> latter would be particularly elegant, as unwind would then become a
>>> patch converter:
>>>
>>>   unwind : p wX wY -> RebasePatch (PrimOf p) wX wY
>>
>> Hmm, yes, that is a good alternative strategy.
> 
> Given the above proof with the added details, we would be fine either way.

I think I'll give the (fixups;prim) strategy a go as I am increasingly
of the opinion that it could simplify a lot of the rebase code. (Or
maybe it won't once I actually try to deal with the extra complications
it introduces.)
 (fixups;prim;fixups) is appealing just from the point of view of
unwind, but I think it'll just cause more pain later. The second set of
fixups are really only of interest to the next patch, not the current
one, and the code will end up a lot more complex dealing with both sets.

----------
title: add failing test for issue2634: rebase of conflicted patches -> add failing test for rebase of conflicted patches

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1902>
__________________________________