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

[Ben Franksen]

Hi Ganesh

Am 30.05.20 um 23:26 schrieb Ganesh Sittampalam:
> On 30/05/2020 21:06, Ben Franksen wrote:
>> Apart from that we are free to push whatever we like, as long as the
>> repo states match up. More concretely, suppose we had a way to determine
>> exactly which parts of the named patch to be amended are in conflict
>> with any rebase items. We could then push only those parts as unchanged
>> fixups, then push the inverse of that together with the amended-in
>> changes under a fresh identity. I think this would restore the behavior
>> that the test expects. I'll have to roll back or obliterate the removal
>> of withManualRebaseUpdate to do that.
> 
> I guess you could just include the whole original patch, as anything
> that doesn't conflict will by definition commute through and fall off
> the end of the rebase.

I think this last statement is not true, see below.

> I think the simplest way to achieve it would be to allow the removal of
> the original patch to propagate fixups in the standard way, like with an
> obliterate or unrecord. But then the addition of the amended patch would
> need to propagate inverse fixups for (original patch+amendment) rather
> than for (amended patch).

Yes, that approach is much simpler and does not require that I resurrect
withManualRebaseUpdate. I have tried it, but unfortunately it does not
lead to the expected result. This is the rebase state before the final
unsuspend (for clarity I removed the patch infos and hashes):

rebase-fixup (
hunk ./wobble 1
-wibble
)
rebase-fixup (
move ./wobble ./wibble
)
rebase-fixup (
rmfile ./wibble
)
rebase-fixup (
addfile ./wibble
)
rebase-fixup (
hunk ./wibble 1
+wibble
)
rebase-toedit (
hunk ./wibble 1
-wibble
+wobble
)

and after unsuspended we get

move ./wobble ./wibble
hunk ./wibble 1
-wibble
+wobble

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

Cheers
Ben