[darcs-devel] [patch1911] WIP: use Prim patches in rebase toedit

[Ganesh Sittampalam]

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

>> But we still need to work out what the actual patch would be, for this
>> to be relevant at all.
> 
> I thought that was clear: the patch we are unsuspending. Formerly a
> RebasePatch prim; now, after the forceCommute of its fixups, a
> 
>   WDDNamed prim ~ WithDroppedDeps (Named (SimpleConflict prim))

I don't think it's that simple (and I didn't think we thought it was
that simple when we last discussed it in the previously mentioned thread).

At the moment when unsuspending fixups :> Named p, we construct
Named (effect p') where merge (inverse fixups :\/ p) = (p' :/\: _), and
put that in the repo.

And then we apply the conflict markup for p' to working.

The problem is how do we get a patch we can use to reproduce that
conflict marking any time the user runs 'mark-conflicts'.

We can't just put Named p' in the repo because that has conflicts with
orphaned prims.

> we duplicate q, so we can push the second q as a fixup into the next
> patch. Suppose this q fixup gets stuck on the next RebasePatch. When we
> unsuspend this next patch, too, the q fixup will get a new identity. I
> think this may result in less than optimal conflict markup when we
> unsuspend multiple patches. We should write a test for what we expect
> the conflict markup to be when multiple conflicted patches are unsuspended.

I was wondering about that too and I agree we need some tests.

My vague intuition was that it's equivalent to the context in a V3
conflictor: if the next patch depends on it then it'll end up as part of
the conflict there and that's the right thing to happen.

Even with the current code using repo patches, I think the result of the
force commute would produce something similar: if you merge (inverse
fixups :\/: q) and get a conflicted result (q' :/\: ifixups'), then q'
will have the effect of inverse (inverse fixups) and ifixups' will have
the effect of inverse q, so when we uninvert the fixups we are pushing
onwards are just q.

But I'm not very confident about any of this. Needs experiments.

Also, using SimpleConflict means we don't get the nice new conflict
resolution algorithm from V3. That may be a significant downside. The
more we discuss it the less convinced I become it's a good solution.

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