Avoiding conflicts in .hgtags
Matt Mackall
mpm at selenic.com
Fri Dec 12 15:14:40 CST 2008
On Fri, 2008-12-12 at 11:05 -0500, Greg Ward wrote:
> On 08 December 2008, Arne Babenhauserheide said:
> > Am Montag 08 Dezember 2008 19:52:14 schrieb Greg Ward:
> > > [merge-patterns]
> > > .hgtags = hgmergetags
> > >
> > > [merge-tools]
> > > hgmergetags.args = $local $base $other > $output
> > >
> > > Script attached. Feedback welcome.
> >
> > I just tried it with groups and then skimmed over the code to see that it
> > needs the layout of .hgtags.
> >
> > What is your reason for not just checking if lines are equal, that way making
> > a merger for any kind of append/remove-only file?
>
> Because .hgtags is *not* an append/remove-only file: tags can be
> changed. The trick is that it *is* a context-free file; you can merge
> three copies of .hgtags by looking at each tag in isolation from the
> others. Because the merge is content-based rather than textual, you
> should only get conflicts when there is a real conflict. (E.g. you and
> I both modify a tag to point to a different changeset, or you modify it
> and I delete it.)
>
> It does seem that there ought to be one merge algorithm for all these
> special .hg* files, but I don't know what it is. Maybe it's not
> possible.
The special files are:
.hgignore
.hgtags
.hgsigs (only with the GPG extension)
All three can be merged just fine by normal textual merge tools.
You could write an automated tool that would handle some of the bogus
conflicts in hgtags, but you'd still have to deal with real conflicts
(two people adding the same tag pointing to different things).
But if you regularly have to merge tags files, you probably have a
process problem.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list