Subject: Re: [PATCH RFC v2 1/4] common-main: split common_exit() into a new file

From: Junio C Hamano <[email-masked]>
Date: Thu, 18 May 2023 10:17:32 -0700

[email-masked] writes:

> It is convenient to have common_exit() in its own object file so that
> standalone programs may link to it (and any other object files that
> depend on it) while still having their own independent main() function.

I am not so sure if this is a good direction to go in, though.  The
common_exit() function does two things that are very specific to and
dependent on what Git runtime has supposed to have done, like
initializing trace2 subsystem and linking with usage.c to make
bug_called_must_BUG exist.

I understand that a third-party or standalone non-Git programs may
want to do _more_ than what our main() does when starting up, but it
should be doable if make our main() call out to a hook function,
whose definition in Git is a no-op, that can be replaced by their
own implementation to do whatever they want to happen in main(), no?

The reason why I am not comfortable with this patch is because I
cannot say why this split is better than other possible split.  For
example, we could instead split only our 'main' out to a separate
file, say "main.c", and put main.o together with common-main.o to
libgit.a to be found by the linker, and that arrangement will also
help your "standalone programs" having their own main() function.
Now with these two possible ways to split (and there may be other
split that may be even more convenient; I simply do not know), which
one is better, and what's the argument for each approach?

> So let's move it to a new common-exit.c file and update the Makefile
> accordingly.
>
> Change-Id: I41b90059eb9031f40c9f65374b4b047e7ba3aac0
> ---
>  Makefile      |  1 +
>  common-exit.c | 26 ++++++++++++++++++++++++++
>  common-main.c | 24 ------------------------
>  3 files changed, 27 insertions(+), 24 deletions(-)