Re: [PATCH 2/3] bisect: fix internal diff-tree config loading

[Jeff King <peff@peff.net>]

On Sun, Mar 03, 2019 at 06:59:19PM +0100, Christian Couder wrote:

> On Fri, Feb 22, 2019 at 7:21 AM Jeff King <peff@peff.net> wrote:
> >
> > When we run our internal diff-tree to show the bisected commit, we call
> > init_revisions(), then load config, then setup_revisions(). But that
> > order is wrong: we copy the configured defaults into the rev_info struct
> > during the init_revisions step, so our config load wasn't actually doing
> > anything.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > It does feel a little weird loading config at all here, since it would
> > potentially affect other in-process operations.
> 
> I like that this patch fixes a bug, but this still triggers some
> wondering/comments.
> 
> Would it be better or at least less weird to load it at the beginning
> of `git bisect`?

I guess you mean at the beginning of bisect--helper? That would be OK
with me, too, and maybe would be a little less weird. But if bisect is
slowly becoming a single binary, maybe we should just wait for that.

> Or is the real problem a limitation of the config system, that prevent
> us from temporarily loading, and then maybe unloading, some config?

It's less the config system, and more the way Git is written. ;)
Typically parsing the config means setting a bunch of globals, and
forgetting what their original values are. That's not something the
config system can fix.

-Peff