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

[Ganesh Sittampalam]

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

> I may be wrong but I think this points out an inherent weakness of doing
> force-commute with conflictors. What such a force-commute really does is
> a purely formal commute, that just exchanges the names of the patches,
> so that patch 'one' now makes the change originally done by 'two' and
> vice versa. I think this is the reason behind the unexpected content of
> the remaining patch 'two' here.

I think it's actually because of the 'effect' call when we suspend. When
we unsuspend, if we have the right fixups and toedits we should get the
right conflicts.

But I haven't actually tried playing with this by hand myself, I'll do
that soon.

> I am looking forward to your experiments with representing the conflicts
> of a suspended conflictor in the rebase patch...

I've made some progress, but the result is nasty - see the bundle I just
sent to this patch.

The basic idea is to unwind a conflict before suspending it, so that the
underlying conflicted patch is stored as a 'ToEdit' and all the context
is stored as fixups.

The trickiest point is that when we are suspending, we have something
like Named (FL RepoPatchV3).

But we need to look at each RepoPatchV3 individually to unwind it. So we
end up with a list like

context1 +>+ underlying_patch1 +>+ context2 +>+ underlying_patch2 +>+ ...

And then in my quick hack we end up with multiple ToEdits for a single
patch we want to suspend.

I suspect that in most cases we can commute them all back together and
squash them back into one, but I'm not sure if that's possible in the
general case.

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