[PATCH 1 of 2] showconfig: add --edit option for editing .hg/hgrc

Matt Mackall mpm at selenic.com
Thu Apr 29 15:10:26 CDT 2010

On Thu, 2010-04-29 at 11:36 +0200, Mads Kiilerich wrote:
> Benoit Boissinot wrote, On 04/29/2010 11:16 AM:
> > On Thu, Apr 29, 2010 at 1:51 AM, Matt Mackall<mpm at selenic.com>  wrote:
> >    
> >> On closer inspection, I see this just invokes an editor rather than
> >> trying to manipulate options directly. But then that give us an
> >> inconsistency between editing ~/.hgrc, .hg/hgrc, /etc/hgrc, etc. And it
> >> might confuse people about where settings come from. I don't think we
> >> need it.
> >>      
> > I still think we could have something better than abort for first
> > users who don't have an hgrc.
> > I can see several possibilities:
> > - default to askuser (and keep a message about no username, see hg help config)
> > - add a command to interactively create a new hgrc
> >    
> Most repos are clones, so they do already have a .hg/hgrc. If users 
> wants "user friendly" functionality for editing the config they can use 
> hgtk. Core Mercurial uses config files which are the users 
> responsibility, but I think we can help the user to edit them. Mercurial 
> controls the name/location, and the user controls the content.
> I notice that usernames usually are set in ~/.hgrc, and not something we 
> configure per repo, but I can see the relevance even though it extends 
> the scope of this proposal.
> We could introduce --edit --user to edit the users hgrc, with the 
> reasoning that it is easier for a user to remember a command name (and 
> get feedback if it is wrong) than remembering the actual filenames.

I consider "knowledge of the existence of and ability to edit hgrc
files" a basic skill in using Mercurial, along with things like creating
a .hgignore file and using merge. And I frankly think forcing users to
manually add their username to such a file on day one is a good thing.
It means any time they read "oh, add such and such to your hgrc", they
already know what you're talking about and have confidence that they can
do it.

Adding paper-thin commands over this stuff accomplishes little to
nothing. It obscures how Mercurial works from the user ("You mean this
file isn't version-controlled? It's just a normal file sitting in a
directory? I can just copy it to other repos manually?") and replaces
one simple, easily discovered, and enlightening piece of knowledge with
another that's obscure and mystifying. With the effort it takes to tell
someone about showconfig --edit, I could have told them "just
edit .hg/hgrc" and they now know more and are more empowered.

That said, I actually think I might be ok with qseries --edit, but only
because I'm lazy and would rather type "hg qs -e" than
"emacs .hg/patches/series". But for this to be acceptable, it'd need to
be clearly documented as nothing more than a shortcut - mq users also
need to know how series (and patch) files work, where they live, and
that they're just normal files that you might want to manually edit,
copy, and revision control.

http://selenic.com : development and support for Mercurial and Linux

More information about the Mercurial-devel mailing list