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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> 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@xxxxxxxx>
> > ---
> > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux