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

[Ganesh Sittampalam]

Ganesh Sittampalam <ganesh at earth.li> added the comment:

> I think this may be related to the question: why is it sound to cancel
> inverses in sequences of fixups or in the context of a patch we forked
> off to the side? I have tried on and off to find a simple theoretical
> explanation for this but failed so far.

My perspective is that we only ever do it in contexts where we don't
rely on the properties of commute/merge, so it's sound for the same
reasons that coalescing is sound in amend/record/pending patch handling:
the theoretical requirements are much lower. But of course it'd be great
if we could deduce a stronger set of properties that still holds even
when we cancel inverses.

> What I had in mind was always a /proper/ conflicted patch, not something
> like SimpleConflict with possibly unsound commute and merge behavior! I
> thought I had made that clear, but apparently I did not.

> Either we can create a proper conflicted patch resulting from a regular
> merge (or a sound and well-tested version of force-commute) or we have
> to store the conflict somewhere else. IMO mixing SimpleConflict with
> regular patches is completely out of the question. With RepoPatchV3 we
> /finally/ have a sound implementation of conflictors and I am not
> willing to jeopardize that just to get a better rebase unsuspend.
> Besides, wouldn't that require us to define how a SimpleConflict
> commutes and merges with /all three/ RepoPatch types?

Sorry, I was unclear here because the discussion arose in the context of
a side comment about returning a resolution directly instead of
SimpleConflict.

If we did create a real patch then certainly it would be a proper
conflicted patch, not a SimpleConflict. It should be trivial to make one
from a SimpleConflict.

> However, there may be a solution that avoids this mixing. The idea is
> similar to how patch queues work in Mercurial. When we unsuspend a
> patch, it will not immediately be converted to a regular patch. Instead
> we have a third sequence of patches in between the regular recorded
> patches and the suspended patches. These patches are applied to the
> working tree and they have their own version of a pristine tree, which
> allows us to directly edit them using amend etc. But we maintain a
> strict separation from the regular patches. When we are done with
> conflict resolution etc, we can convert them to regular patches.

Interesting idea in general. Maybe we could also build more
functionality into rebase to help with these kinds of workflows.

>> BTW a good example where you really care about what actually happened in
>> an amend comes from things like move and replace patches. There's an
>> example in the 'rebase-move.sh' test:
> 
> Right again. I knew all that at some point but forgot the details. Sorry
> for needing you to remind me ;-)

It took me a while to remember this point myself :-)

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1911>
__________________________________