Worthwhile and low-priority, as far as I can tell. Implementor should
maybe watch out for things like quoting/escaping
There's a danger of this adding another pebble to our pile of config
mechanisms. I'm tempted to mark this need-design and say, whoah we need
to think config a bit more carefully, things like:
- how do we avoid a proliferation of config mechanisms?
- how do we make it clear what sort of config travels from repo to repo
(eg. boring file if you save it), and what sort is really just for one
repo only?
- what config is meant to be read by other darcs? (motd)
- environment variables - why do we use them?
- how do we continue to offer levels of control (global vs local vs one-
off?)
- how does this fit with command line switches
I don't want to get in the way of progress, just saying that this could
be the sort of thing we'd want to get right in Darcs 3. (There could
also be things to learn from Git here, dunno)
|