Mercurial and Agile

[Gilles Moris]

On Thu July 2 2009 03:31:40 Matt Mackall wrote:
> There are basically two fundamental operators in our world: diff and
> patch. There's a third operation called merge, which is actually built
> from the first two. And there's a fourth (backout) which is a
> combination of patch and merge. And there's a fifth (rebase) which is
> basically a series of merges.
> 
> We can define a fairly complex "cherrypick" operator like this:
> 
> a-o-p-s-o-o   s is the change we want to pick, p is its parent
>  \
>   o-o-d       d is where we want it to end up
> 
> First check out p:
> 
>  hg up -C p
> 
> Then get change s in our working directory, without changing our parent:
> 
>  hg revert -a -r s
> 
> Now do a 'reverse merge' (needs 1.3) to the ancestor:
> 
>  hg up a   # linearly transplant change s to a -> s'
> 
> Now do a 'forward merge' to d:
> 
>  hg up d   # transplant s' to d -> s''
> 
> 
> Ok, so that gets us a nice three-way merge, and if we're lucky, does so
> without any user intervention. If we're unlucky, we might be launched
> into the resolve process not once but twice. The fiddly bits turn out to
> be hard to avoid.
> 

Hi Matt,

Do you think we can have an integrated cherrypick command that does exactly
that for 1.4 ? Can this common workflow and recurring request be automated ?

Another question: besides the fact that hg forbids to cross branches, is there
a conceptual difference between the 2 successive merges p->a->d and a straight
merge p->d ? If not, is this desirable to have a force flag to allow update
to cross branches to do it in one step ? IOW, why do we prevent 'update' to
cross branches ?

Best regards.
Gilles.