On config files and aliases

[Jan Hudec]

On Wed, Mar 08, 2006 at 23:21:01 -0600, Matthew D. Fuller wrote:
> In advance, I'm going to suggest "yes" and "no" as the answers to the
> following questions, but on the latter I think it should be a
> conscious decision to go with "no".
> 
> 
> First question: Should bzr create its primary config file
> (~/.bazaar/bazaar.conf) if it doesn't exist?  It's kinda nice to have
> /something/ there no matter what.  Filling it in with the default
> email address (whether from env vars or from the user at host) would also
> make it easier to point somebody at exactly what to change where; it's
> nicer than saying "Create this directory, then create this file in
> that directory, then precisely follow this format".  Easier to say
> "Edit this file and change the email".  This comes up particularly at
> the moment in relation to...

Yes. Most other programs do this as well.

> Second: We have command aliases now, settable in the config file
> per-user, which have a superset of the capabilities of built-in
> aliases[0].  What if we moved all the existing command aliases over to
> be managed in that format?  Problem: It would require writing out the
> 'default' set when created (as above), as well as requiring edits in
> existing configs.  Potentially bigger problem: The alias set is locked
> in when the user first runs the command, irregardless of later
> upgrades (or we try incredibly nasty and fragile rewriting crap).

Maybe, but without writing out anything and without locking anything at
first use.

That is, bzr reads config files. It reads /two/ config files currently
-- ~/.bazaar/bazaar.conf and ~/.bazaar/branches.conf. IMO it could also
have a global config. This would be part of the distribution but allow
easy site-wide customization. It requires config sections to be
combined, which they *SHOULD* anyway.

Though on the other hand, I am not sure it will really win anything.

> Really, there are so many reasons to answer "no" on that, that it's
> hardly even worth considering (which is probably why nobody has
> publically).  If it weren't for the generally twitchy feeling I get
> seeing essentially the same thing done in two different ways in
> parallel, I wouldn't either.  But, as above, I think it deserves a
> public beating before being laid to rest.
> 
> 
> 
> [0] One difference is that "bzr help <alias>" doesn't currently work
>     (and making it evaluate in the same way can be difficult; think
>     loops).  "bzr <alias> --help" does, though.  Actually, a "bzr
>     aliases" command to list aliases, and "bzr aliases <alias>" to
>     show what it evaluates out to, would be nice, and then on top of
>     that "bzr help <alias>" could show the expansion, then the help
>     for the command it points to.  Haha!  And it should cure the
>     common cold, and whiten your teeth while you sleep!
> 
> 
> -- 
> Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>            On the Internet, nobody can hear you scream.
> 
-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060309/5387cab6/attachment.pgp