Re: [PATCH 4/4] config: don't implicitly use gitdir

[Jeff King <peff@peff.net>]

On Mon, Jun 12, 2017 at 11:16:27PM -0700, Brandon Williams wrote:

> > If the parameter is now required, then it might make sense for it to
> > become an actual function parameter instead of being stuffed into the
> > config_options struct. That would give you your breaking change, plus
> > make it more obvious to the reader that it is not optional.
> > 
> > The downside is that has to get shuttled around manually through the
> > callstack. Most of the damage is in builtin/config.c, where we call
> > git_config_with_options() a lot.
> > 
> > include_by_gitdir is also a bit annoying, as we pass around the
> > config_options struct through our void-pointer callbacks. But we can
> > solve that by sticking the git_dir into the include_data struct (whose
> > exact purpose is to carry the information we need to handle includes).
> > 
> > The patch below (on top of Brandon's series does that).
> 
> I really don't understand why this has to be so difficult and why a
> 'breaking change' is even needed.  Duy just added the 'git_dir' field to
> the config_options struct in April of this year (2185fde56 config:
> handle conditional include when $GIT_DIR is not set up) and now we want
> to strip it out again?  That's not even two months. Seems very counter
> productive and makes the api more unwieldy.

I could go either way on it. But note that you're not just changing the
existing opt->git_dir behavior.

If I call git_config_with_options() without having set opt->git_dir, the
call will now quietly ignore repo config. But even before opt->git_dir
existed, calling that function would always have read from repo config
(when we're in one, of course). So if there's a patch in flight that
adds a call to git_config_with_options(), it's now very subtly broken.

The reason I say "I could go either way" is that we can make a guess as
to whether there are any topics in flight that add such a call.

There aren't any in pu right now. That's not the whole world, of course;
people may have topics they haven't yet published. Or they may have long
running forks. Git for Windows is one, and I maintain one that GitHub
uses internally. But GfW is public and doesn't have any new calls (and
nor does my fork).  In general, it's kind of an unlikely call for a fork
or a new branch to add.

So at some point I think we say "good enough, it's not worth the hassle"
and this may be such a case.

-Peff