[PATCH] Check for .hgrc files in ancestor directories above the repository
peter.arrenbrecht at gmail.com
Tue Jan 15 08:56:00 CST 2008
Guys, I tried to recap this thread in the wiki:
If I misrepresented anyone or anything, feel free to correct. Hope
this helps to get nearer to a decision (if necessary by inviting input
On Jan 14, 2008 4:54 PM, Peter Arrenbrecht <peter.arrenbrecht at gmail.com> wrote:
> On Jan 14, 2008 4:11 PM, Jesse Glick <jesse.glick at sun.com> wrote:
> > Peter Arrenbrecht wrote:
> > > I still lean toward Maxim's proposal. No repeating of path patterns
> > True. I think its (minor) disadvantages are that (1) it is a little more
> > to document (you need to specify a new section name, and need to specify
> > how filenames are resolved); (2) you can't see all your configuration in
> > one file; (3) using "re:...' syntax for patterns is impossible because
> > keys cannot contain ':' (though '[...]' would likewise not be possible
> > inside section names). I don't have a strong opinion though.
> I think (1) is rather minor.
> Agree with (2).
> Re (3): Kludgy [include-re] and [include-glob] come to mind. Or even
> something like:
> hg = glob:/sources/hg/*
> hg = ~/.hgrc-hg, ~/.hgrc-python
> Not that I like it particulary. But your mention of : being forbidden
> in keys might lead to problems with Windows drive specs as well. Of
> course, with this one could also go for:
> hg = glob:/sources/hg/*, glob:/sources/old/hg/*
> [default at hg]
> log = -M
> which would mean your approach also does not repeat patterns, allows
> multiple specs per set, and still keeps all config in one file. I
> think I rather like it.
> > > trivial reuse of existing config parser.
> > Using @-sections would not involve parsing any additional files at all,
> > much less changes to the existing config parser; just a small block in
> > localrepo's constructor to copy keys from matched sections into the
> > normal section names, before parsing .hg/hgrc.
> I see. That's not an argument then.
> Who makes the final decision, anyway? Matt?
More information about the Mercurial-devel