[darcs-devel] [patch1947] refactor simplifyPush (and 9 more)

[Ganesh Sittampalam]

> I was just arguing that the incremental canonizeFL of two fixups that we
> currently do when we add a single fixup could be replaced with a
> canonizeFL of the full sequence after adding the new fixup to the head.

OK, makes sense as a possibility.

> I am no longer quite we can get away with first canonize then commute.
> What about the following: we add a hunk that replaces line 1 with a new
> line to a hunk that does the same for line 2. I think these currently
> commute. But if we first canonize then this will join them into one
> hunk. So canonizing can not only create new opportunities for
> commutation, it can also remove some. So we cannot scrap the initial
> attempt at commuting a fixup through the whole sequence. So it would
> have to be: first try commuteFL, otherwise add to the head and
> canonizeFL and then extract to see if we can pull out new patches to
> push into the next item.

And if we do succeed in commuting after the canonizeFL, do we need to
canonize again? Or is it guaranteed that any subset of the result of a
canonize is also canonized?

I realised that there are other problems with maintaining the desirable
invariants (fixups are canonized, fixups are minimal). One example,
though there could well be others, is that we also move fixups around
without canonizing when we are commuting the patches they live inside.
And if we did canonize during that process, we might risk breaking the
commute laws.