Cherry picking

[Brendan Cully]

On Friday, 25 January 2008 at 19:26, Jesse Glick wrote:
> Matt Mackall wrote:
> > "regularly pick some subset of changes from a source and remember 
> > which things we didn't want" [...] is maybe best solved by merge +
> > backout.
> 
> Perhaps, though this assumes that you know for certain which things you 
> are not going to want by the time you cherry-pick their descendants, 
> which I don't think is true. For the purpose of backporting bug fixes 
> from a active development repository to a release stabilization branch, 
> where approval to backport a particular fix may come days after it has 
> been developed (when testing has revealed no hidden problems), the 
> Transplant extension looks tolerable, except that:
> 
> 1. The original changeset ID is at best stored as a comment, not as 
> first-class metadata. (It is also stored inside .hg, but as this 
> information is not shared with clones, it is not very useful.)

It's embedded in the 'extra' dictionary in the changelog - I think
that counts as first-class metadata.

> 2. There is no protection against an accidental attempt to transplant 
> the same changeset twice (in different clones).

hrm. transplant itself will not pull the same changeset over twice,
even if you've cloned.

> 3. Should you try to merge the branch back into trunk - i.e. if some 
> people have been making fixes directly in the branch that you want to 
> recover, and no release-specific changes such as changing the product 
> version label from "Dev" to "2.0" have been made in the branch yet - 
> then the merge may get confused by trying to reapply transplanted 
> changesets.

reapplied changes can be tricky, yes. There are some ideas about this
on the transplant wiki page, but nothing much has been developed.

> As I understand things, a VCS like Darcs can represent patches 
> explicitly and would understand that a given repository revision 
> contains a fragmented subset of available patches. Probably a VCS like 
> Mercurial which represents revisions in a DAG would be able to fully 
> support cherry-picking if it assumed by default that a DAG node 
> contained all patches implied by its ancestry yet was able to store an 
> addendum of extra and missing patches. The merge algorithm would get 
> more complicated in this case; you could still use a 3-way merge tool to 
> do the work, but in some cases you would need to run it several times in 
> sequence.