Re: [PATCH v5 2/2] submodule: pass on http.extraheader config settings

From: Jeff King <peff@peff.net>
Date: Apr 28, 2016, 21:20 UTC
Message-ID: <20160428212011.GC12268@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZF4UeNuwBoA-Vw0OFHin4=8GTWPK-GT+5fsEuCFe7Now@mail.gmail.com>

On Thu, Apr 28, 2016 at 02:08:43PM -0700, Stefan Beller wrote:

Show 9 quoted lines

> >   1. Ones where we _know_ that the config is nonsense to pass along,
> >      _and_ where a user might conceivably make use of the
> >      just-the-top-level version of it (core.worktree
> >      comes to mind, though of course they are probably better served by
> >      "--work-tree" in such a case).
> 
> My gut reaction to this:
> In this specific case I would rather error out, as you never want to have
> core.worktree to point at the same dir for all of the repo and submodules.

But then you're erroring out on a case that currently works today (we apply core.worktree to the root repo, and ignore it for the others), which I think is worth avoiding.

Show 5 quoted lines

> Thinking about it further, I am not so sure any more.
> (What if you have multiple submodules tracking the same project
> and you want to see each submodule version with the one worktree you point to?
> Highly unlikely edge case, but it voids the /never/ assumption of my
> gut reaction)

I think this falls in my "nonsense" category. Especially when there are other ways to handle it (e.g., by asking "git submodule foreach" to look at each directory).

> I view the whitelist more like an "emergency knob to turn, because the
> developers did it wrong and I want it now". the general case should be
> covered by a mechanism we provide?

I think the emergency knob is "visit each submodule individually if you have want to do something clever in each one" (or "ask git not to recurse into submodules" for the opposite effect). The use cases I have seen discussed are:

  1. Convenience. People expect to set some global-ish config like
     credential.helper, and have it applied uniformly.

  2. Inserting config into awkward parts of the call chain. E.g., I
     think Lars is mostly interested in speeding up clones where the
     submodules have a lot of slow clean/smudge filters. So he wants to
     disable "filter.*" _just_ for the clone, but there's no easy way to
     intercept the clone step of each submodule, stop, and the run the
     individual checkout with "git -c filter.foo.smudge=". I'm sure
     there's probably a way to hack it with plumbing, but it fails in
     "convenience".

-Peff