On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:
> > The only downside I can think of is that we might want to use the
> > subsection in "include.SUBSECTION.*" for some other limiting conditions
> > (e.g., "only include this config when running version >= X.Y", or even
> > "include only when environment variable FOO is true").
>
> It seems as though gitconfig doesn't have a standard way of dealing
> with 'sub-subsections', which is essentially what this is trying to
> implement.
Right. Syntactically, the config keys are:
SECTION.SUBSECTION.KEY
where SUBSECTION is optional. SECTION and KEY cannot contain spaces or
dots and are case insensitive, but SUBSECTION is handled literally. It
can contain whatever data is useful to the config parser (for example,
remote names, branch names, or even URLs), including spaces or dots.
We could introduce the notion of sub-subsections, but that would not
play well with existing uses of subsection, which assume that they can
put arbitrary data into it.
> It makes sense that there could be different 'modes' of includes.
> These could be the ones you mentioned already, such as repo and env,
> but could also be things like branch where the config changes
> depending on which branch you are on. Ideally, multiple entries per
> mode would be allowed.
>
> Implementing all that initially would be overkill however if this sort
> of functionality is desirable the ability to easily add new modes
> would be a great boon down the track.
Right. We don't have to decide on all of it now; we just have to leave
the door open syntactically for future growth.
> The four pieces of information we need to include are that this is an
> include, the path to the include, the mode, and the mode specific
> parameter. Your proposal is to allow the sub-subsection by
> concatenating with a ":" like this
>
> [include "<mode>:<mode-param>]
> path = <path>
Right. The config parser does not care about the sub-subsection; it is
up to the interpreter of the key to split the subsection if it chooses.
I arbitrarily chose ":" as the internal delimiter because I thought it
looked nice. You could make it dot or space, too.
> Alternatively, we could allow chaining of subsections (couldn't find
> any previous discussion on this) by adding whitespace between each
> subsection. Seems like lots of potentially unnecessary work, but maybe
> this has already been discussed or is the most appropriate way of
> doing it.
>
> $ git config --global include.repo./magic/.path ~/.gitconfig-magic
>
> [include repo "/magic/"]
> path = .gitconfig-magic
I don't think it has been discussed before. But as I mentioned above,
you would not want to apply this everywhere. For existing config
callbacks, they want to take the section literally. So it is going to be
up to the callback to parse the section into subsections anyway, at
which point it does not really matter what syntax you use.
We could teach the config parser to normalize:
[section with many spaces]
key
as "section.with.many.spaces.key" or "section.with many spaces.key" (I
do not think it is even valid in today's code, but I didn't check). But
personally I do not find that any easier to read or understand than the
colon syntax.
> This seems like the easiest and most flexible method, and doesn't
> require any 'special' considerations for the subsection. It would be
> harder for a user to configure, and the concept of a mode seems less
> intuitive.
>
> $ git config --global include.magicrepos.mode repo
> $ git config --global include.magicrepos.param /magic/
> $ git config --global include.magicrepos.path ~/.gitconfig-magic
>
> [include "magicrepos"]
> mode = repo
> param = "/magic/"
> path = ~/.gitconfig-magic
Yeah, that is the most flexible. You could introduce multiple conditions
or other options, as well (e.g., instead of mode and param, have
include.magic.repo, include.magic.env, etc). But it seems like
over-engineering. I do not mind making the code a little harder to
write, but it seems unnecessarily complicated for the user, too.
> Of the three I probably think the subsection chaining is the nicest
> overall, though your original "repo:" proposal seems to be the easiest
> to implement.
I think I favor the colon proposal because of its simplicity. And
because the sub-section chaining cannot be applied consistently across
config keys, I don't think there is much value in trying to introduce a
new general config syntax.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html