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

Ben Franksen ben.franksen at online.de
Fri Oct 4 11:49:49 UTC 2019


>>> 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).

Sorry if I forgot something we already discussed, I probably did not
understand things properly back then. My understanding of what happens
during unsuspend has improved but still wasn't 100% clear

> 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.

Okay, thanks for spelling it out to me again. I think I got it now ;-)

More on this in separate message.

>> 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.

Yes, it will end up as part of the next conflict, but I think conflict
resolution, as far as I understand it, will treat this as a /new/
conflict, independent of the previous one, at least for V3. The q we
push into the next suspended patch is treated if it were an
independently created duplicate of the first q.

> 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.

Yes, I think this is independent of your refactor. If I am right, then
we should see the same (suboptimal) markup with the current rebase.

> 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.

I am not sure using e.g. RepoPatchV3 instead of SimpleConflict helps. I
think SimpleConflict just captures the fact that we forget the
identities of the fixups we have force-commuted through a suspended patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20191004/7a255e1d/attachment.key>


More information about the darcs-devel mailing list