how to refactor path duplication in .mrconfig section headers?

[Adam Spiers]

On Fri, Oct 28, 2011 at 8:03 PM, Richard Hartmann
<richih.mailinglist at gmail.com> wrote:
> On Fri, Oct 28, 2011 at 18:45, Joey Hess <joey at kitenet.net> wrote:
>> mr can look much nicer if you take advantage of locality and chaining.
>> By locality, I mean putting a mrconfig close to the directories it
>> checks out, rather than in some standards-body controlled directory like
>> ~/.config.
>
> You mean that ~/.git-repos contains the actual repos?

By "you" are you referring to me or Joey?  Yes, my intention
was that ~/.git-repos contains all git repos (or at least most).

> I.e. that every repo comes with its own .mrconfig?

If you mean, every repo *contains* its own .mrconfig, then
I don't see how that would work - wouldn't it create a chicken
and egg situation prior to first checkout?

> I used that approach at first, but
> I feel the symlinks (here they are ;) from ~/.config/mr/available.de
> to ~/.config/mr/config.d are more flexible.

I like that scheme with things like apache (sites-available
vs. sites-enabled) although with mr config, the same effect can by
automated via the special 'skip' parameter, which to me seems nicer
than manually fiddling with symlinks.

> Plus, you get central management of all mr configs.

Right on the money!  This is the real reason I want all my mr configs
in one place - I want them within a single git repo which I can
version control everywhere.  Then bootstrapping my entire environment
is as simple as:

    [$HOME/.config/mr]
    checkout = ...
    chain = true

> That can be handy when you want to make a global update on a machine
> which does not have all your mr-controlled repos checked out.

If I understand that correctly, you are saying pretty much the same
thing as me.