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

From: Jeff King <peff@peff.net>
Date: Oct 2, 2014, 20:41 UTC
Message-ID: <20141002204106.GA4556@peff.net>
In-Reply-To: <xmqq1tqqnud1.fsf@gitster.dls.corp.google.com>

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

Show 12 quoted lines

> 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