[Monotone-devel] Re: Trying to understand the ideas behind cherrypicking...

[graydon hoare]

Nathan Myers wrote:

> > I don't much like "transplant", but I'm not quite sure why.  
>
>
> In a different context I once suggested "splice".

I'm leaning toward "cp" myself, since it serves to abbreviate "copy" and 
"cherrypick". also it's not many keystokes to type.

as far as implementation, I really just think it'll be sufficient to 
take the changeset from one revision and append it to another. future 
merges are based on "live" difference analysis of composite edges, so 
shared similarity between merge edges should just the merge easier. 
nothing special to record.

there is one tricky part of course: if affected files in the destination 
context don't have the same source IDs (thus a non-exact cherrypick), 
you have two options:

 - produce a unified diff and feed it to patch, or an internal
   implementation of what patch does. might be nice to have.

 or

 - for file change A->B on state C, perform the 3-way merge A->B
   against A->C (note: A->C is a synthetic edge, but this does
   not matter). either calculate the edits A->C by concatenating
   A->LCA(A,C)->C, or just calculate the normal diff(A,C).

I'm sort of in favour of the second approach, since we probably have all 
three files on hand and can calculate the diffs on the fly; it reuses
more of the existing machinery and likely produces the same or better 
result. but I'm open to experiments.

-graydon