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

From: Christian Couder <christian.couder@gmail.com>
Date: Apr 16, 2024, 11:01 UTC
Message-ID: <CAP8UFD0W7PUHTg2NwuVkQJik2+HqTDF6KRZZ8tA_dW7-YZtsbQ@mail.gmail.com>
In-Reply-To: <20240401023225.GA2639800@coredump.intra.peff.net>

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

Show 20 quoted lines

> 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.