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

From: Jeff King <[email-masked]>
Date: Wed, 22 Jul 2015 22:14:45 -0700

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

> 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.

> 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