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

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 11, 2026, 12:15 UTC
Message-ID: <ansSfYBPm6lZc7jB@pks.im>
In-Reply-To: <al6yCTDjBRn2HGq0@com-79390>

On Mon, Jul 20, 2026 at 06:40:57PM -0500, Taylor Blau wrote:

Show 29 quoted lines

> On Mon, Jul 20, 2026 at 03:43:50PM -0700, Junio C Hamano wrote:
> > I do not think we want to do this in a single large change.  If we
> > were to move everything to 'lib/' only to then need to further group
> > them into subdirectories of 'lib/', it would subject us to multiple
> > rounds of disruption.  I suspect it would be far less disruptive if
> > we migrated one subsystem at a time, directly to a new directory
> > immediately below the root level.
> 
> I agree.
> 
> Though it may seem *more* disruptive to do it piecemeal instead of all
> at once, I think it would be preferable to avoid having a single
> subsystem have to move multiple times.
> 
> That said, I am not sure that I completely understand the motivation
> behind such a change to begin with. The second patch in this series
> claims that:
> 
>  - "The Git project is not exactly the easiest project to get started in
>    [...]", because in part:
> 
>  - "[..] finding your way around in our project's tree is not easy.
>    Doing a directory listing in the top-level directory will present you
>    with more than 550 files, which makes it extremely hard for a
>    newcomer to figure out what files they are even supposed to look at."
> 
> I am not sure I understand how moving ~700 some odd files into "lib" makes
> the project easier to navigate. I understand the patch's latter point
> that:

I guess the motivation is still not clear enough then. My maint intent isn't really to make individual files in "lib/" more discoverable. Ultimately, I agree with you that they're not really becoming magically more discoverable themselves, except...

>  - "It is not obvious at all which files are part of "libgit.a" and
>    which files are only linked into our final executables."

... that it's becoming clearer which files are part of libgit.a and which are not. And that to me is already a benefit by itself.

But what I care about is to make everything else more discoverable. We have a bunch of files and directories in our toplevel that are relevant to developers, and especially newcomers will have a hard time to even discover them when they're looking at 561 files.

> But don't see how this distinction will help newcomers who are likely
> not yet thinking about which files are part of libgit.a and which are
> not.

They're not. But they'll care about there being a README.md, SECURITY.md, a conde of conduct, a license, installation instructions, build systems, and the various subdirectories that we have. All of these files are currently getting completely drowned out by the noise.

> My other thought is that I worry that "lib" might itself be somewhat
> misleading, given that many of the files being moved are not especially
> amenable in the current form to being linked against as external
> libraries.

Fair, but they still result in "libgit.a".

Thanks!

Patrick