[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