[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