> I had to think about this a bit to understand what's going on with
> the unrevert patch. First the user splits unrecorded into 'norevert'
> then 'p' (the stuff to be reverted). But the unrevert patch
> needs to be relative to recorded, not unrecorded. So we need
> to commute p with norevert, and if that fails then keep some
> of norevert in the unrevert patch so it still makes sense. This
> patch is about minimising how much of norevert we keep, rather than
> the existing all/nothing decision.
Exactly. It took me a while to figure that one out myself. Should put a
comment in the code, perhaps just copy and paste what you wrote above.
|