[issue918] Option to copy some of .hg/hgrc upon local clone

[Peter Arrenbrecht]

On Jan 9, 2008 9:12 AM, Thomas Arendsen Hein <thomas at intevation.de> wrote:
> * Jesse Glick <mercurial-bugs at selenic.com> [20080107 23:13]:
> > New submission from Jesse Glick <jesse.glick at sun.com>:
> >
> > Sometimes there are important pieces of configuration in .hg/hgrc which (1)
> > cannot be in global config, (2) would make sense in most or all clones of that
> > repo as well (just not in unrelated repos).
> >
> > In particular, ui.username may need to have a project-specific value. For
> > working on Hg sources, I want to use my full email address. For working on
> > NetBeans sources, I want to use 'jglick' - a login ID tied to authentication and
> > other site functions such as bug tracking.
>
> But if you are on a multi user system and someone clones from you,
> he will start to commit with your ui.username.
>
> This isn't theoretical, I clone from coworkers.

I thought the idea was to only do this when you are the owner of the
cloned repo. Will admittedly be hard for FAT, but when in doubt, just
don't copy, I guess.

>
> > When doing an initial clone of the remote repository, I need to remember to set
> >
> > [ui]
> > username=jglick
> >
> > which is OK. But when I do a local clone, I need to remember to set it again,
> > which is irritating.
>
> You could also call it consistent :)
>
> > It would be nice if there were some way to mark in hgrc that certain sections
> > ought to be copied to the new hgrc after a local clone (subject to the normal
> > security checks, i.e. only if cloned by the same user). Perhaps
> >
> > [clone]
> > username.ui =
> >
> > and the clone command would check for any keys listed in this section and try to
> > copy them.
> >
> > Would be happy to supply a patch if it is agreed the enhancement would be desirable.
>
> Maybe you can talk to Glenn Ammons who suggests an extension to make
> certain hgrc parameters accessible over the network, too.
> If your ideas are combined, you could e.g. transfer the repository
> description during cloning, regardless of local clone or over the
> network (to get consistent behaviour).

Hmm. That would work for globally applicable things, but not for local
ones. But maybe it really is much simpler to just use a custom script
to clone hg repos locally.

Different idea: An hg extension that augments clone so it looks down
the folder tree for a .hgrc file which could then contain directions
as to what to copy on clone. This on the assumption that different
local clones of the same project usually are all in the same parent
folder. Would also be a nice way to have different .hgrc settings for
the numerous local clones different projects.

Now that I think of it, maybe such a cumulative .hgrc (down folder
hierarchy + ~/.hgrc), with values closer to the project overriding
more distant ones, would already solve the problem without the need
for copying things on clone. Would this be acceptable as a general
mechanism? Might be configured in ~/.hgrc so it's not active by
default.

I cannot, at first glance, see any serious security problems with
this, but performance could suffer a little bit.

-peo