[darcs-devel] FullUnwind rebase behaviour

Ganesh Sittampalam ganesh at earth.li
Sun May 17 17:59:39 UTC 2020


On 17/05/2020 14:09, Ben Franksen wrote:

> Yes, forceCommuting (a^,b) pushes b which cancels with b^, so c appears
> unconflicted and we get a;a^;c as the effects of the unsuspended
> patches. This is bad.
> 
> More generally, a patch that conflicts only with already conflicted
> patches has no effect and thus no pre-fixups. The only way I can think
> of to make it remember its conflictedness in the suspended state is by
> not pushing the trailing fixup that inverts the patch itself; instead
> keep it attached to the suspended patch. More generally, fullUnwind of a
> conflicted patch [r,x,c:p] could be a quadruple (r,c,p,p^c^). This may
> mean we can no longer cancel/commute out all intermediate fixups in a
> suspended Named patch and perhaps must go back to my old proposal of
> introducing a RebasePatch type and using Named (RebasePatch prim).
> 
> Even if we do that, it is not at all guaranteed that this will solve all
> problems. For instance, how do we classify fixups added to rebase when
> we amend or unrecord or obliterate a patch? Should they be treated as
> dependencies or as conflicts? Or as some third thing?

I think those would generally be dependencies. Certainly obliterating a
patch should result in dependency fixups: consider a pair A;B where B
depends on A. If you obliterate A you want "dependency" fixups.

I'm not sure I'm understanding your proposal fully though. How do you
propose distinguishing "dependency" versus "conflict" fixups?

> Also, going back to the simple conflicted pair a\/b, their suspended
> state is either (,a,)(a^,b,b^) or (,b,)(b^,a,a^). Should we add this as
> a commutation rule for suspended patches? Can we generalize this rule?
> Or do we accept that conflicting patches no longer commute when suspended?

It certainly sounds quite complicated. I'm more wondering if we should
accept non-linear structure within the rebase state. For example if we
used a DAG, we might be able to represent conflicts in terms of the
conflicting patches directly. But it's a lot of complexity in another
direction.

Ganesh


More information about the darcs-devel mailing list