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

[Mads Kiilerich]

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.

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

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

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

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

/Mads