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

[Nathaniel Smith]

On Thu, Nov 25, 2004 at 09:07:59PM -0500, graydon hoare wrote:
> 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.

Oh, please don't.  "cp" is way too established as a file operation;
_everyone_ will assume that it goes with add/drop/rename...

How about "monotone patch"?  That's basically the operation; maybe a
bit more likely to work than an actual diff -urN, but no other history
sensitivity, no magic VCS history recording -- works just like a diff
-urN | patch.

> 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 are edge cases, of course; you end up doing unnecessary work if
you cherrypicked from branch A to branch B, then on branch B further
edited some of the code affected by the cherrypick, and then merge
branches A and B -- you'll have to merge any affected hunks by hand,
even though branch B's code should automatically win.  This is a
pretty minor case, though, yeah, and only applies in the first place
when you do plan to do a full merge later.  (Which many of the posited
examples for cherrypicking -- backporting fixes to release branches,
trading fixes between FSF Emacs and XEmacs, etc. -- assume will never
happen.)  It can also be worked around by hand, if we ever get around
to adding a merge command that lets you explicitly specify which
ancestor to use -- you'd get a workflow like
  1. start merging A and B
  2. run into a bunch of spurious conflicts caused by the old
     cherrypick
  3. grumble and poke at the history to see when the cherrypick
     happened
  4. merge A-just-before-the-cherrypick with B-head, using the normal
     merge ancestor
  5. merge A-head with the result of that merge, using
     A-just-after-the-cherrypick as the merge ancestor.
A little annoying, definitely, but not the sort of thing that's going
to eat more than a few minutes of time.

> 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.

I dunno; why would we want to get into the heuristic context-sensitive
patch application guessing game, when there are pre-existing tools
with all the functionality and a lot more time and eyeballs and knobs
to twiddle?

>  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).

This is definitely the way I've been thinking of cherrypicking working
in Monotone (and thanks to Joel, we already have almost exactly this
code in mainline's 'update' command -- only difference is that it
uses the merge code's DOM+ANC algorithm rather than an LCA algorithm).
It adds almost no new code -- we re-use the merge code from
update/merge/propagate, just using a new "walk the graph to build a
changeset between arbitrary revisions" primitive -- and this has
UI/consistency benefits too... plus, it should work better than doing
context diffing anyway, so we're getting better, cleaner functionality
for less work...

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein