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

Ben Franksen bugs at darcs.net
Tue Oct 1 22:12:35 UTC 2019


Ben Franksen <ben.franksen at online.de> added the comment:

>> For example, in a V3 Conflictor I am pretty sure we could, instead
>> of using contexted patches that fork off to the side, use a
>> linearized version where we flatten each contexted patch followed
>> by its inverse and include that in the linear sequence (i.e. the
>> effect). The only question here would be why we can ignore their
>> relative ordering when linearized in this way. I think the reason
>> for that is that they must have originated as forking patches: if
>> we start with a\/b, then a;a^ :> b;b^ should trivially commute.
> 
> So we'd need a special commute rule for pairs like a;a^?

Yes, I think so (and also similarly for FLs and RLs). Note that this is
a theoretical consideration and not meant to be implemented.

>>> But given we have a goal of getting some patch into the repo that
>>> will allow "darcs mark-conflicts" to reproduce the unsuspend
>>> conflicts, my feeling was that it might be going in the wrong
>>> direction.
>> 
>> I think this goal is unattainable if we go this route i.e. use
>> only prims in rebase. We cannot construct "real" conflicted patches
>> except by merging. And the prims you push into rebase have
>> deliberately forgotten which Named patch they once belonged to (if
>> any), so you cannot know from which point in the past you need to
>> merge.
> 
> I don't think such conflicts would ever refer to the repo's history.

Yup.

> They'd just be there so the user could use mark-conflicts to get the 
> markup back.

I'd like to know what "being there" means, more concretely.

> When unsuspending, the "toedit" prims would end up in the Named patch
> the user had originally suspended,

Okay, this works because the "toedit" is not conflicted (even if it was
when it became suspended...

> and the "fixup" prims would end up in some new dummy Named patch.

Where do you store this patch? You cannot possibly plan to mix it with
normal patches... =:-/

>>> BTW please ignore D.P.R.Conflict.toSimpleConflict, it's not
>>> used.
>> 
>> If it is not used then how else are SimpleConflicts introduced in
>> the first place? extractRebaseChanges calls toWddNamed which calls 
>> toSimpleConflict...
> 
> toWddNamed calls a function with a subtly different name and
> location: D.P.R.Patch.toSimpleConflicts.

Okay, missed that one due to the name collision.

>> On a more general note, I have been wondering if perhaps the whole
>> idea of building rebase on prims goes in the wrong direction. What
>> if we go in the opposite direction and try and get rid of fixups?
>> We could replace them with "real" conflicts, that is, pushing a
>> fixup would be replaced with merging, together with some notion of
>> forceCommute that would have to be implemented as a primitive
>> operation in our 3 RepoPatch types. The obvious problem with this
>> is that sometimes we don't have a RepoPatch but only prims, e.g.
>> when we amend a patch.
> 
> I think the two big downsides are that real conflicts are much more 
> complicated than the rebase representation, and that we still
> (probably) need some appropriate point to do a canonize. At the very
> least we need cancellation of inverses, though perhaps we can already
> capture that in merge operations somehow.
> 
> On the other hand if we could do it, it might allow us to remove a
> whole load of extra infrastructure related to rebase patches.

I agree that we will have to canonize at some point. I was thinking that
maybe we could postpone that to the last possible moment, that is, when
we create new (unconflicted) patches on unsuspend.

That still leaves open the question of how to represent/store conflicts
when we unsuspend.

>> I think the correct solution here would be to push a merge between
>> the old and new versions of the amended patch.
> 
> The special treatment that amend gets in rebase is important in
> practice - at least, I wrote it after realising that amending
> otherwise doesn't work well. You really need to use the actual diff
> being amended in. The RebaseName operation rename is also important
> for updating explicit deps.

I agree with all that, but my intuition tells me that we can achieve the
same with merging. I must admit that I haven't thought this through in
detail, yet. Anyway, here is a rough sketch.

Suppose we have suspended patches R that start after A. We amend A to B
and have to adapt the rebase state. So we merge B\/(A;R) and get
A';R'/\_ of which the lhs A';R' is the resulting new rebase state. The
A' retains all the information we need: we could recover the difference
between A and B as prim fixups from it (including rename fixups) if we
want. Indeed this A' /is/ a rebase fixup, just not as a prim, but
instead as a regular Named patch, tagged with a boolean flag to
distinguish it from other suspended patches. Like our current fixups we
won't normally show it to the user. Similarly, a suspended patch that we
rebase obliterate just turns into such a fixup. And a regular patch that
we obliterate gets pushed into rebase as a fixup w/o any further changes.

Okay, so now we unsuspend R (or some part of it) and let us suppose this
depends on the A'. So we use our primitive force-commute on A':>R to
get... what? I don't know yet what the result of a force-commute should
be. Need to think about that. This is the interesting part where all the
rebase magic happens...

One thing that is clear to me now is that we would need a special
implementation of force-commute for Named patches that handles the
explicit dependencies: if we force-commute P:>R, where R has an explicit
dependency on R, we need to represent the loss of that dependency; this
is what we currently do with the WDDNamed wrapper and I guess we'd need
something quite similar here.

Cheers
Ben

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1911>
__________________________________
-------------- 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/20191001/375ce39c/attachment.key>


More information about the darcs-devel mailing list