[darcs-devel] conflicted rebase (or rather: rebase with conflicted fixups)

Ganesh Sittampalam ganesh at earth.li
Sun May 31 10:36:15 UTC 2020


Hi,

On 31/05/2020 10:21, Ben Franksen wrote:

> The problem here is that the (rmfile ./wibble; addfile ./wibble) pair is
> stuck on the patch to be edited. In the old rebase these would cancel
> each other and then we could commute the (move ./wobble ./wibble) past
> and drop it.

(I think) we'd never have got the pair because we would have directly
pushed in the move without the rmfile/addfile.

> I think this can be fixed, though. I currently simply inject all stuck
> fixups. This is allowed because conflicts can always be commuted into
> proximity, so we know that the stuck fixups cannot be ones that later
> items conflict with. But we can do better than just injecting
> everything: we could first cancel inverses and then try again to commute
> fixups past. I think this would solve the problem here. I will try to
> improve the inject procedure to do that.

If you cancel inverses, aren't you just returning to the old behaviour?
If you push in

  (fixup original patch; fixup (invert (original patch;amendment))

Then the copies of original patch will cancel and give us just the
amendment.

Overall I haven't yet got what we gain from having conflicted fixups. I
understand why conflicted "toedit" patches are worthwhile: we keep
information about the full conflict structure, which means suspended
resolution patches remain valid. Do we need conflicted fixups just to
make sure that V3 conflicts in toedit patches remain valid? And might it
be enough just to have named prims in fixups?

Cheers,

Ganesh


More information about the darcs-devel mailing list