[PATCH 3 of 4] hgmerge: remove obsoleted code, update docs

Matt Mackall mpm at selenic.com
Mon Jan 7 22:46:21 CST 2008


On Mon, 2008-01-07 at 22:19 -0600, Steve Borho wrote:
> On Mon, 2008-01-07 at 18:10 -0600, Oliver Xymoron wrote:
> > On Mon, 2008-01-07 at 15:20 -0600, Steve Borho wrote:
> > > +  Example ~/.hgrc:
> > > +
> > > +    [hgmerge]
> > > +    default = kdiff3
> > > +    ext.html = myHtmlPlugin
> > > +    ext.lib = takemine
> > 
> > Extension-based is a little limited. The decode/encode filters can take
> > patterns. It's a bit odd to have a [merge] and an hgmerge section, if
> > we're making this core functionality.
> 
> There isn't currently a merge section as far as I know, only ui.merge.
> But I have no problem naming the new section just [merge].  Using file
> patterns that would look like:

There is, it's just undocumented. There are two settings, followcopies
and followdirs, that are there for debugging. Other stuff might show up
there eventually.

> [merge]
> default = kdiff3
> **.html = myHtmlPlugin
> **.lib = takelocal

It's been pointed out that the above style as used by filters would be
better if it were turned around, due to parsing limitations in
ConfigParser:

 myHtmlPlugin.pattern = **.html

But we might get to that later.

> > The 'plug-in' terminology isn't great as it makes it sound much more
> > substantial than it really is (typically two lines of config). It'd be
> > even better if we could get it down to one line in the typical end-user
> > case, ie:
> 
> The intent was to eventually allow python 'plug-ins', in which case they
> would be more substantial.

I know. I think I still prefer "tool" or even just to put it all under
[merge], if we can think of a tidy way to do that.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list