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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 11, 2026, 16:33 UTC
Message-ID: <xmqqpkzo39d2.fsf@gitster.g>
In-Reply-To: <ansSg4qsPwh5FcR9@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 18 quoted lines

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