[PATCH] Per-host remotecmd option in .hgrc

Matt Mackall mpm at selenic.com
Mon Oct 3 14:47:41 CDT 2011


On Mon, 2011-10-03 at 12:43 -0500, Matt Mackall wrote:
> On Fri, 2011-09-30 at 20:20 -0500, Augie Fackler wrote:
> > On Sep 30, 2011, at 8:14 PM, Matt Mackall wrote:
> > 
> > > On Sat, 2011-10-01 at 01:11 +0200, Mads Kiilerich wrote:
> > >> Matt Mackall wrote, On 09/30/2011 09:36 PM:
> > >>> On Thu, 2011-09-29 at 22:25 +0400, Dmitry Samersoff wrote:
> > >>>> dsamersoff: Per-host remotecmd option in .hgrc (issue359)
> > >>>> 
> > >>>> Patch below allows user to setup per-host remotecmd in the .hgrc file
> > >>>> in the form:
> > >>>> 
> > >>>> [ui]
> > >>>> remotecmd = /opt/bin/hg
> > >>>> remotecmd.mircat.net =/opt/csw/bin/hg
> > >>> Well I can't think of a better solution short of adding a bunch of
> > >>> per-host sections.
> > >> 
> > >> This adds another way of doing host-specifc configuration, different 
> > >> from what we already have for hostfingerprints and auth.
> > > 
> > > Agreed, we should aim for some uniformity here.
> > > 
> > >> I think it 
> > >> would be slightly better to add a remotecmd section. That could perhaps 
> > >> simplye be "implemented" by documenting it as
> > >> [ui.remotecmd]
> > >> mircat.net = ...
> > > 
> > > Hmm, that's not especially appealing. And it sort of implies a similar
> > > trick can be done for all ui settings.
> > > 
> > > The various sections existing per-host settings look like this:
> > > 
> > > [auth]
> > > foo.prefix = example.com/path
> > > foo.username = bob
> > > foo.schemes = http https
> > > 
> > > [hostfingerprints]
> > > example.com = 38:76:52:7c:87:26:9a:8f:4a:f8:d3:de:08:45:3b:ea:d6:4b:ee:cc
> > > 
> > > ..so it's already a bit late to be consistent unless we do something
> > > more drastic.
> > > 
> > > Also, we probably want to specify ui.ssh in a consistent fashion.
> > > 
> > > I think we should seriously consider replacing this mess with a
> > > consistent per-host schema of some sort.
> > 
> > [hosts] # Not actually thrilled with this name on account of it working for local paths too, but oh well?
> > foo.prefix = example.com/path
> > foo.username = alice
> > foo.fingerprint = 38:76:52:7c:87:26:9a:8f:4a:f8:d3:de:08:45:3b:ea:d6:4b:ee:cc
> > foo.remotecmd = /we/put/hg/over/here/hg
> 
> > Seems perfectly reasonable to me. Could probably even write a contrib
> > script to suggest the right results based on the user's current
> > config. Anything I'm missing that we should consider?
> 
> One issue is that we've got multiple protocols mixed up in here. So, for
> instance, the fingerprint only applies to SSL (and not SSH!) and
> remotecmd only applies to SSH. Also, you might possibly have different
> usernames for http/ssh on the same host. The [auth] section deals with
> this with the schemes marker, which lets you have a foo that applies
> only to ssh and a bar that applies only to https. But that's rather
> suboptimal. It might be better to have:
> 
> foo.username = alice
> foo.username.ssh = aliceb
> 
> Also, Mads' trick can be applied here:
> 
> [hosts]
> foo.val = x
> 
> is the same as:
> 
> [hosts.foo]
> val = x

It occurs to me that we'll also eventually want things like per-host
hooks ("when I push to host X, set a bookmark.."), which means we'll
want to plan a sensible schema for that here. We should probably just go
through all of the config settings to make sure there's nothing we might
be forgetting here.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list