[PATCH 0 of 2] The ui.ignore config option, one more time

[Laurens Holst]

Op 19-09-13 22:46, Matt Mackall schreef:
> On Thu, 2013-09-19 at 21:45 +0200, Isaac Jurado wrote:
>> Replying Isaac Jurado:
>>> This is another attempt to change the behaviour of ui.ignore.*
>>> configuration option to a more useful one.
>>>
>>> The idea is to leave absolute paths as they are, but interpret relative
>>> paths from the repository root instead of the current working directory.
>>> Specially since the latter can be emulated with something like:
>>>
>>>      [ui]
>>>      ignore = $PWD/custom-ignore
>>>
>> As Matt requested last time this was brought up, I've been quickly
>> reviewing the behaviour of relative paths in other situations where
>> external files must be opened in some way.
>>
>> For all the following cases, absolute paths work fine and
>> util.expandpath() is used, so the ~ and $ expansions work as expected.
>> The comments are only for cases where a relative path is used (i.e. the
>> result of util.expandpath() still being relative):
>>
>>                       |  relative to     |  documented
>>    -------------------+------------------+--------------
>>      %include         |  current config  |  yes
>>      shell aliases    |  shell rules     |  implied
>>      command hooks    |  repo root       |  no
>>      python hooks     |    ????          |  ??
>>      .hgsub           |  repo root       |  yes
>>      ui.ignore.*      |  current wd      |  no
>>      paths.*          |  see NOTE        |  no
>>      extensions.*     |  current wd      |  no
>>      merge-tools      |  $PATH lookup    |  yes
>>      email.method     |  shell rules     |  yes
>>      auth.{key,cert}  |  current wd      |  no
>>      web.cacerts      |  repo root       |  no
> Shiny. Let's sort this differently:
>
>                       |  relative to     |  documented
>    -------------------+------------------+--------------
>      %include         |  current config  |  yes
>      .hgsub           |  repo root       |  yes
>      merge-tools      |  $PATH lookup    |  yes
>      email.method     |  shell rules     |  yes
>      shell aliases    |  shell rules     |  implied
>      command hooks    |  repo root       |  no
>      web.cacerts      |  repo root       |  no
>      paths.*          |  see NOTE        |  no
>      ui.ignore.*      |  current wd      |  no
>      extensions.*     |  current wd      |  no
>      auth.{key,cert}  |  current wd      |  no
>      python hooks     |    ????          |  ??
>
> I think we all agree that "current wd" behavior is pretty much
> useless/meaningless for config settings. We once had such behavior for
> hooks and changed it. So it becomes a question of "relative to hgrc" or
> "relative to repo root". I think the latter is probably the most
> sensible choice.

The problem with specifying relative to repo root is that you can not 
easily predict where the file will be. There is no direct relation 
between the specification of the location and the actual file location. 
You need to know about a lot more things before you can determine which 
file is read. Especially when you put this in global or included hgrc’s, 
things can get pretty messy.

Paths being relative to the location where they are specified is a 
common and simple mechanism. This is also how relative URLs work; if you 
have an XML file containing a relative path that gets loaded into an 
existing web page, the path should be resolved to the XML file’s URL, 
not the web page that loads it.

So IMO it should look up the path relative to the exact configuration 
file it is specified, or the current working directory when specified on 
the command line.

Some old threads for reference,

http://selenic.com/pipermail/mercurial-devel/2010-June/021462.html
http://selenic.com/pipermail/mercurial-devel/2011-November/035741.html
http://selenic.com/pipermail/mercurial-devel/2013-April/050735.html
http://selenic.com/pipermail/mercurial-devel/2013-April/050677.html
http://selenic.com/pipermail/mercurial-devel/2013-July/052057.html

https://www.google.nl/search?q=site:selenic.com%2Fpipermail%2Fmercurial-devel%2F+%22ui.ignore%22+relative

~Laurens