Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

From: Jeff King <peff@peff.net>
Date: Jul 23, 2015, 05:14 UTC
Message-ID: <20150723051445.GA24029@peff.net>
In-Reply-To: <20150723044007.GA3651@gmail.com>

On Wed, Jul 22, 2015 at 09:40:10PM -0700, David Aguilar wrote:

Show 12 quoted lines

> On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote:
> > This patch adds an option to turn on --first-parent all the
> > time, along with the corresponding --no-first-parent to
> > disable it.
> 
> [Putting on my scripter hat]
> 
> I sometimes think, "it would be really helpful if we had a way
> to tell Git that it should ignore config variables".
> 
> This is especially helpful for script writers.   It's pretty
> easy to break existing scripts by introducing new config knobs.

I think the purpose of --no-first-parent here is slightly orthogonal. It is meant to help the user during the odd time that they need to countermand their config.

Script writers should not care here, because they should not be parsing the output of the porcelain "log" command in the first place. It already has many gotchas (e.g., log.date, log.abbrevCommit).

I am sympathetic, though. There are some things that git-log can do that rev-list cannot, so people end up using it in scripts. I think you can avoid it with a "rev-list | diff-tree" pipeline, though I'm not 100% sure if that covers all cases. But I would much rather see a solution along the lines of making the plumbing cover more cases, rather than trying to make the porcelain behave in a script.

> That way, script writers don't have to do version checks to
> figuring out when and when not to include flags like
> --no-first-parent, etc.

One trick you can do is:

  git -c log.firstparent=false log ...

Older versions of git will ignore the unknown config option, and newer ones will override anything the user has in their config file.

Show 6 quoted lines

> Would something like,
> 
> 	GIT_CONFIG_WHITELIST="user.email user.name" \
> 	git ...
> 
> be a sensible interface to such a feature?

I dunno. That's at least easy to implement. But the existing suggested interface is really "run the plumbing", and then it automatically has a sensible set of config options for each command, so that scripts don't have to make their own whitelist (e.g., diff-tree still loads userdiff config, but not anything that would change the output drastically, like diff.mnemonicprefix).

-Peff