Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables

[Jeff King <peff@peff.net>]

On Thu, Oct 02, 2014 at 12:29:14PM -0700, Junio C Hamano wrote:

> Tanay Abhra <tanayabh@gmail.com> writes:
> 
> (just this point quick)
> 
> > 1> The name of the variable, I could not decide between "unset.variable"
> > and "config.unset", or may be some other name would be more appropriate.
> 
> I'd prefer to see this as [config] something.
> 
> I wish we did the include as "[config] include = path/to/filename",
> not as "[include] path = path/to/filename".  Perhaps we can deprecate
> and move it over time?

I chose [include] because I had intended there to be multiple include
variables (include.path, include.ref, etc). The others were shot down
for now. If we put it under [config], I'd still prefer to leave room by
calling it:

  [config]
  includePath = path/to/filename

I also wanted [include] as a section name to leave room for
conditional includes. We've sometimes discussed things like:

  [include "has-some-git-feature"]
  path = ...

to allow conditional inclusion only when git supports a certain
feature-set (so that your config doesn't cause git to blow up when you
use an old version of git). It's possible that I'm the only person in
the world who really wants that, because I run old git versions all the
time for testing and debugging. And it is kind of gross as a syntax. But
it would still be nice to leave room for it.

I don't think there's a reason we couldn't allow:

  [config "condition..."]
  includePath = ...

in the same way if we wanted to (though aside from includes, I do not
know of any other feature that would want the condition).

So I'm not _opposed_ to adding [config], deprecating [include], and
waiting a bit before dropping [include]. But I also don't really see the
current name as a particularly bad thing.

-Peff