Re: git should not use a default user.email config value
- From
Jeff King <peff@peff.net>
- Date
- Aug 13, 2013, 15:53 UTC
- Message-ID
- <20130813155345.GA23391@sigill.intra.peff.net>
- In-Reply-To
- <CAH5451nxgpa4Q-BpwhD7yD6V6_LWBP=+oEDR3u0eGErSWNEBbQ@mail.gmail.com>
On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:
Show 8 quoted lines
> > 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.
Show 9 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 10 quoted lines
> 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]
keyas "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.
Show 13 quoted lines
> 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