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

Patrick Steinhardt <[email protected]>
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
On Tue, Aug 11, 2026 at 09:33:29AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email protected]> writes:
> 
> >> ... built-in commands in 'builtin', with subsystems like 'refs' and
> >> 'odb' in their own directories, and everything else at the root
> >> level, I would prefer to keep that organization until a substantial
> >> subsystem update wants to carve out a new location for itself, just
> >> as past updates to create 'builtin', 'refs', and 'odb' did.
> >> 
> >> Compared to those past moves, the proposed change looks more like
> >> churn for the sake of moving things around, without achieving any
> >> real organizational improvement.
> >> 
> >> I must say that I, too, remain skeptical.
> >
> > My main motivation isn't prettiness though, it's newcomers to the
> > project. Git is not an easy project to get started in, and the root
> > cause of that of course isn't our file layout but probably rather that
> > Git has been growing organically for 20 years. But the file layout
> > definitely doesn't help newcomers to find their way around in the
> > product.
> 
> What I gave as good examples were not motivated by prettiness,
> either.  Moving things around to lib/ as a whole ball of wax without
> further classification would mean readers, whether new or old, would
> not benefit from neatly classified set of files that gives readers a
> concise and easy to understand rules like "you can visit builtin to
> learn about individual command implementations".  To achieve a layout
> that makes it easier to find our way around, you'd need to move
> things again after moving everything into lib/.  Moving to lib/ by
> itself does not add much value, if any.  It certainly does not add
> any discoverability.

I think that a cleaned up root directory is by itself already adding a
lot of value because it makes the entry points into the Git codebase
more explicit. As I said elsewhere, the value is not in making the code
that is part of "lib/" itself more discoverable. The value is in making
everything else more discoverable.

Ultimately though it's a subjective change, so it's hard to argue about
that as I cannot present any hard facts.

Thanks!

Patrick
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.