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

[Laurens Holst]

Op 20-09-13 11:21, Laurens Holst schreef:
> 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

I guess this search is better:

http://markmail.org/search/?q=list%3Acom.selenic.mercurial-devel+%22ui.ignore%22+relative

~Laurens