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

Matt Harbison mharbison72 at gmail.com
Sat Jul 11 13:18:12 CDT 2015


On Sat, 11 Jul 2015 05:53:19 -0400, Erik Huelsmann <ehuels at gmail.com>  
wrote:

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

Yes.  Get everything fixed up and tested, and patchbomb will handle the  
details if you give it the proper revisions.

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

Generally, each individual patch should summarize what _it_ does.  You can  
mention that it is a step towards X in the body if that isn't clear.  Scan  
back even 50 or so commits in the hg repo, and you will see several series  
by the same author to get the idea.

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

Just an FYI, the code freeze is in a week, after which it will have to  
wait until Aug 1.

> Thanks for the prompt response!


More information about the Mercurial-devel mailing list