[PATCH 3 of 3 V2] merge: add automatic tag merge algorithm

[Angel Ezquerra]

On Mon, Mar 24, 2014 at 1:52 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 03/24/2014 12:33 PM, Angel Ezquerra wrote:
>>
>> I think we should definitely be able to configure a _fallback_ tag
>> merge tool which is run when this merge algorithm fails to merge
>> (because of conflicts). However, if we guarantee that the default the
>> algorithm never does the wrong thing (i.e. that it only successfully
>> merges the .hgtags file when there are no conflicts and there is only
>> one valid way the merge should be done), shouldn't we always accept
>> that correct merge result?
>
>
> We can change Mercurial if it fixes bugs or are areas that previously were
> undefined or failed badly. Merging of .hgtags is something where we clearly
> have told users that they were on their own ... and users might have found
> their own way of doing it. Some users might rely on something that is
> clearly "incorrect". One example could be to ignore all .hgtags changes when
> merging to release branches and only accept tags done on the release branch.
> I think we have to be very careful when introducing automatic merging.

OK, that is a good point.

>> Imagine that we turned this algorithm into an actual merge tool (lets
>> call it hgtagmerge, for example). This would have several drawbacks:
>>
>> 1. There would be no way to configure mercurial to use a fallback
>> merge tool for .hgtags. You could either use the default merge
>> algorithm or your own tool, but not both (unless I misunderstood the
>> way merge-patterns work). This means that if I wanted to use WinMerge
>> (for example) to resolve .hgtags conflicts (instead of the default
>> KDiff3 tool that TortoiseHg uses for most file types), I would not be
>> able to do so while still using the default merge algorithm.
>
>
> I don't understand this ... unless it is the same as the next:

I guess they are two sides of the same problem.

>> 2. When the hgtagmerge algorithm fails we want to revert to a regular,
>> old-style text merge, so that the user can use his merge tool of
>> choice to do the merge. I don't think (but I may be wrong) that it is
>> possible to configure mercurial to call a second merge tool if the
>> first one that you specified via a merge pattern fails.
>
>
> I would say that the tool should be so good that we think it can solve all
> common and not-so-common cases.
>
> In the rare case where it fails I think it would be fine if it failed with
> "error: .hgtags cannot be merged automatically - use 'hg merge --config
> merge-patterns..hgtags=!' to resolve with your normal merge tool" ... or
> suggest 'hg merge --tool kdiff3 .hgtags'. Users who end up here are doing
> weird stuff. Let's give them the power and responsibility for working it out
> instead of adding more conceptual complexity.

The thing is that users don't need to do very weird stuff for a fully
automated merge to be impossible. Two different users may decide that
a different revision must be tagged "A". That is an actual conflict
that no automated merge tool can resolve. I don't think forcing the
user to manually write some complex command line incantation in a
perfectly normal scenario is a good idea. hg is not git :->

What I'd like is to have a way to configure mercurial to first try the
internal:hgtags tool, and then try some other tool in case of failure,
while still letting users completely override the automatic merge
algorithm as you suggest.

What about this?:

- We add an internal:hgtags tool as you suggest.
- We add a config entry that lets the user select a fallback hgtags
merge tool. For example "merge-tools.internal:hgtags.fallback".
- internal:hgtags runs the automatic merge algorithm (with the
improvements you suggested). If merge-tools.internal:hgtags.fallback
is not set the default text merge tool is run when internal:hgtags
fails. Otherwise the fallback tool is run.

I think this would give us the both of both worlds. We would let users
completely override the default merge algorithm, and it would let most
users get automated merges with their desired fallback tool.

What do you think?

>> 3. The user could choose to use the hgtagmerge to merge any filetype
>> of his choice. Does it ever make sense to use this merge algorithm
>> (which is quite specific to the .hgtags format) for any other sort of
>> file?
>
>
> http://www.catb.org/jargon/html/D/Don-t-do-that-then-.html
>
> I imagine it could be 'internal:hgtags'. It should perhaps be mentioned
> somewhere in the documentation but I don't think it would have to be shown
> in the merge-tools help topic.

OK.

>> As I said I'd rather not turn this into
>> a full blown merge tool unless you really think I should.
>
> I think a "less than perfect" tool could be fine as something users can
> decide to configure in merge-patterns. That could be a fine first milestone.
>
> I think it has to be "perfect" before we can consider enabling it by default
> ... and even more so if there is no way to opt out.

Depends on what you consider "perfect". IMHO it is OK for a "perfect
merge tool" to fail when there are unsolvable conflicts. Do you agree?

Cheers,

Angel