Re: [PATCH RFC v3 2/2] Move libgit.a sources into separate "lib/" directory

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2026, 14:27 UTC
Message-ID: <xmqqqzk2t7sm.fsf@gitster.g>
In-Reply-To: <693a61b6-e762-d864-d25b-348485ec039e@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

> Of course, it would be even nicer if `lib/` was split up further, but
> then:
>
> 1) You've got to start _somewhere_. As we saw with so many things on this
>    list, they never materialized because reviewers asked for too much and
>    weren't happy to get incremental improvements first.

That is why moving everything to 'lib/' and thinking about the rest later will not work. Instead, moving a specific component to a specific subdirectory (not 'lib/') would be a reasonably self-contained first step. Consider 'builtin/' as an example: it is focused, and anyone can easily tell what the criterion is. If it is the top-level cmd_foo() implementation, it goes there; otherwise, it does not. Then, you can proceed to the second step, and then the third. Iterate enough times, and the top level will become thin enough that you can either make your final step a no-op and leave the remaining files there, or create one last group to house the hodgepodge of leftover bits and move them there.

Show 6 quoted lines

> 2) Naming is hard. As we saw with _many_ refactorings (I am thinking about
>    the low-level merge stuff as well as the ODB stuff, for example), it is
>    unlikely to get the origanization right the first time. So I'd think
>    that first moving the bulk of the library code to lib/ is a good start,
>    and worth merging, leaving later contributions to chop off further
>    parts into subdirectories of lib/.

Again, this is because you are trying to do everything at once. Instead, come up with one clear concept, name it well, move the related files there, and then iterate.