Re: [PATCH v2] bisect: Honor log.date

[Christian Couder <christian.couder@gmail.com>]

On Mon, Apr 1, 2024 at 4:32 AM Jeff King <peff@peff.net> wrote:

> I guess that commit is what brought me into the cc. I have not been
> following this topic too closely, but generally I'm in favor of using
> "git show". I even suggested it back then, but I think Christian
> preferred not using an external process if we could avoid it.
>
> The thread from 2019 is here:
>
>   http://lore.kernel.org/git/20190222061949.GA9875@sigill.intra.peff.net
>
> which links to the earlier discussion about "git show":
>
>   https://lore.kernel.org/git/CAP8UFD3QhTUj+j3vBGrm0sTQ2dSOLS-m2_PwFj6DZS4VZHKRTQ@mail.gmail.com/
>
> IMHO this config thing is a good example of the strength of the separate
> "show" process. If our goal is to trigger all the niceties of "git
> show", it is tricky to catch them all. The revision machinery is pretty
> reusable, but there's no easy way to figure out which config affects
> git-show and so on. Of course if we had a way to invoke git-show
> in-process that would work, but I suspect there are unexpected corner
> cases that might trigger.

Sorry for not following the topic closely and for replying to this so
late, but I think that by now we should have some kind of guidelines
about when forking a new process is Ok and when it's not.

It seems to me that there was already some amount of back and forth on
this topic when bisect and other shell commands were ported to C a
long time ago. There weren't clearly written guidelines, but it seems
to me that at that time we thought that forking a new process was
generally bad, especially for performance reasons, but also because
they showed a bad example and didn't go in the right direction. It
seems to me that people who reviewed code that ported some commands to
C sometimes asked contributors to not fork processes, and efforts were
made by contributors, like GSoC or Outreachy contributors I mentored,
to go in this direction. At one point there was even a microproject
about replacing code that forked a process with function calls.

These days there are also talks and patches around about libification
and about passing around a "repository" variable and other such
variables, so that C code does not need to fork processes to be able
to work more broadly, for example in submodules. And again it seems to
me that such changes (adding code which starts a new process to
replace code which doesn't) doesn't go in the same direction as the
libification and similar goals.