[PATCH V2] merge: Add support for 'union' merge strategy

Erik Huelsmann ehuels at gmail.com
Sat Jul 11 04:53:19 CDT 2015


Hi Matt,

On Sat, Jul 11, 2015 at 1:25 AM, Matt Mackall <mpm at selenic.com> wrote:

> On Fri, 2015-07-10 at 20:10 +0200, Erik Huelsmann wrote:
> > # HG changeset patch
> > # User Erik Huelsmann <ehuels at gmail.com>
> > # Date 1435346089 -7200
> > #      Fri Jun 26 21:14:49 2015 +0200
> > # Node ID c8b0c9fb18ec813244b100e7ecf9ee5eb7b92f88
> > # Parent  ff5172c830022b64cc5bd1bae36b2276e9dc6e5d
> > merge: add support for 'union' merge strategy to internal merge tool.
> >
> > 'union' merge is a merge strategy where the left and right side of a
> > conflicting merge are merged into the target without generating a
> conflict.
> >
> > One use-case for this merge strategy is the Changelog file being changed
> > on multiple branches and conflicting when being merged back to the main
> > branch.
> >
> > The idea for this merge strategy has been taken from Git.
>
> This looks ok, but it's a bit much going on in one patch by our
> standards. Could I get you to split it up into the following pieces:
>
> - bits that add start/end_marker (but please, no _ in new names)
> - bits that union option to simplemerge
> - bits that split out filemerge helper function
> - bits that add union merge + test of same
>

Ok. I can split it up that way, no problem. Just verifying before diving
in: are you expecting it as a set of patches ('1 of 4'...)? Each with the
same commit text as I provided above? Or are you expecting the last patch
with the commit text as above, and the others with a shorter description
like "In preparation of implementing union merge, rearrange ...."?


Also, we may want the start/end marker business to be fully internal to
> simplemerge rather than passing in more args.
>

Consider it done! :-)

I'm a bit spotty on time availability, but I'll get to resubmitting the
patches; hopefully without too much delay.

Thanks for the prompt response!

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150711/604a9137/attachment.html>


More information about the Mercurial-devel mailing list