[PATCH 5 of 6] config: give it a mapfile option, for parsing them specially

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon May 4 19:45:06 CDT 2015

On 05/02/2015 03:49 AM, Yuya Nishihara wrote:
> On Sat, 02 May 2015 00:56:20 -0400, Jordi GutiƩrrez Hermoso wrote:
>> # HG changeset patch
>> # User Jordi GutiƩrrez Hermoso <jordigh at octave.org>
>> # Date 1430344009 14400
>> #      Wed Apr 29 17:46:49 2015 -0400
>> # Node ID c06e371d76b759b900b34120d8d3e90a63790660
>> # Parent  5adc92b85bfe045bfd527d836eccad53a5568e92
>> config: give it a mapfile option, for parsing them specially
>> It is desirable to "derive" templates from the provided templates. A
>> simple way to do this is e.g.
>>      %include map-cmdline.default
>> in your own mapfile. Then you only have to redefine a few templates
>> instead of copying over the whole thing. This %include mechanism
>> already works for the built-in templates because by default it *only*
>> looks for files that are in the same directory as the including
>> mapfile.
> I have mixed feelings about this. It must be nice that we no longer have
> to write custom templates from scratch. On the other hand, this means all
> template variables defined in map files are public interface of Mercurial.

Template is an awesome feature of Mercurial and that seems a good way to 
push it forward. could we have a public/_private notation to "reduce" 
this effect?

Pierre-Yves David

More information about the Mercurial-devel mailing list