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

Jesse Glick jesse.glick at sun.com
Sat Jan 12 11:25:14 CST 2008


Peter Arrenbrecht wrote:
> the new proposal is:
> 
>   Scan for trusted .hginclude files in parent dirs up to /.
>   For every such file found:
>     Read the string it contains.
>     Sanitize the string so it does not contain path separators.
>     Ensure the string starts with .hgrc.
>     Read the file ~/<string> (for example ~/.hgrc-netbeans or
> ~/.hgrc-something-else), again ensuring it is trusted as for normal
> .hgrc files.

Still sounds quite weird to me. You need multiple config files (in 
different formats) to accomplish one task.


Here's a fresh proposal that I think covers the use cases securely and, 
I hope, more intuitively:

Check in global config files (~/.hgrc, /etc/hgrc, Mercurial.ini, etc.) 
for a section called (for example) 'clonedefaults'. Each key must be a 
dot-separated triple of (possibly abbreviated) hash of repository 0 
revision [1], section name, and regular key name. Any matching 
repository will pick up the default setting, overriding keys in the 
.hgrc but overridden by keys in the .hg/hgrc. For example, NetBeans' 
"main" repository will likely have the first changeset imported from CVS 
(and that in turn from StarTeam, may it burn in hell):

changeset:   0:203e82b1b502
user:        Ian_Formanek
date:        Tue Jan 05 17:21:34 1999 +0000
summary:     #

Therefore my ~/.hgrc could read:

[ui]
username = Jesse Glick <jesse.glick at sun.com>
[clonedefaults]
203e82b1b502.ui.username = Jesse Glick <jglick at netbeans.org>
9117c6561b0b.email.to = mercurial-devel at selenic.com

Now any time I am working with some variant of the NB main repository 
anywhere on my laptop, the username is set correctly. Works regardless 
of how I got that particular clone. All other repositories will pick up 
the @sun.com username. Whenever I am working on some clone of Hg 
sources, patches will be sent to the devel list by default.

This all assumes that it is cheap and feasible to read the identity of 
the 0 revision before parsing .hg/hgrc. If it is not so cheap, perhaps 
this tidbit of information should be cached in e.g. .hg/identity 
(written if holding a write lock and not already present); it can never 
change for a given clone so there is no concern about staleness. Anyway 
if there is no clonedefaults section, there is no penalty to pay.

Would it work? Would it be understood easily?


[1] In the case that a repository has multiple revisions with null (-1) 
as the parent, the clonedefaults could match against _any_ of these 
direct children. That covers situations where you import history from 
another repository, regardless of the order in which the import happened 
for the local user. That said, I expect it would be exceedingly rare for 
people's clones to differ in their choice of 0 revision even after such 
an import (under the assumption that the history import happened on only 
one occasion, in a specific direction), and just checking 0 might be 
faster than looking for all children of -1.



More information about the Mercurial-devel mailing list