[PATCH 5 of 6] config: give it a mapfile option, for parsing them specially
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Tue May 5 00:45:06 UTC 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