Re: How to extend a patch theory to fully commute

The final chapter about the effect of extended patches and how to
resolve the conflicts they represent could use a bit of elaboration. For
instance, though you refer to the process, you haven't explained how
(extended) patches are merged. I think you will need to introduce
inversion for this. This is probably quite simple but maybe still worth
writing down explicitly.

I find the last chapter hard to follow because I don't quite understand
the motivation. It sounds as if what you are saying here is that we
cannot merge patches from another repo as long as our repo is
conflicted. But that cannot be true if all patches can be commuted. Or
is this about /recording/ new patches in a conflicted repo? Some
clarification would be helpful.

Also, this paragraph is unsatisfying:

> After some quick thinking, Pseudo managed to find a patch P' which was
> equivalent in effect to P. However, this turned out not to be a great
> solution, since although P' had the same effect as P, it had the name of
> a completely different patch, which was confusing. Moreover, the space
> required to store P', and computing power needed to commute it, was more
> than one should rightfully expect from a simple primitive patch.

I think this should either be extended to explain how P' was
constructed, or it should be left out.

Cheers
Ben