Re: git should not use a default user.email config value

On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:

quoted

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