[PATCH] Check for .hgrc files in ancestor directories above the repository

[Peter Arrenbrecht]

I'm happy now. Jesse? If this is OK for you too, we should approach
Matt again, I guess.

I think we should state clearly that the items in [include] are
processed first to last. So config elements in later includes override
those in earlier ones. This since more than one include item might
match a given repo.

-peo

On Jan 12, 2008 9:09 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Sat, Jan 12, 2008 at 08:24:46PM +0100, Peter Arrenbrecht wrote:
>
> >Hi Maxim, hi Jesse,
> >
> >On Jan 12, 2008 3:31 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >>
> >> What about
> >>
> >> [include]
> >> ~/hg/ = ~/.hgrc-hg
> >> ~/mutt/ = ~/.hgrc-mutt
> >>
> >> syntax in config?
> >>
> >> The first one is directory prefix to match, the second is config
> >> to include if repo directory matches.
> >>
> >> Basically we get:
> >>
> >> 1. No security risks.
> >> 2. Flexibility.
> >> 3. Single config, so easy to debug.
> >
> >I like this very much! How about combining it with Jesse's approach,
> >so we would have
> >
> >~/.hgrc-203e82b1b502
> >~/.hgrc-9117c6561b0b
> >
> >Then we would not even need any special configuration in ~/.hgrc. Just
> >add the above files to configure clones of particular 0-revisions.
>
> I would prefer to explicitly specify this in main config. I don't
> really like "additional config by default" idea.
>
> You may safely combine it within main configuration though.
> Something like
>
> [include]
> node:203e82b1b502 = ~/.hgrc-something
>
> would be probably usefull.
>
> >Maxim's approach would make it unnecessary to get at rev 0's hash
> >efficiently (no need for, possibly, an additional cache in .hg). And I
> >guess it's easier to understand. How about using the already known
> >convention of glob/regex to specify custom .hgrc-xy files?
> >
> >  [include]
> >  glob:~/dev/hg/** = ~/.hgrc-hg
> >  re:~/dev/netbeans/.* = ~/.hgrc-netbeans
> >
> >with glob being the default? (Forgive me if the patterns are not quite correct.)
>
> No problem with it.
>
> >Jesse's idea, however, would transparently capture all clones of a
> >particular base rev, wherever they are located.
> >
> >I like both, but I think Maxim's config approach is easier to grasp.
> >That's just my view, though.
>
> See above. We can easily extend [include] section with root node
> matching while still keeping concept simple.
>
> Maxim Dounin
>