From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>,
"Elijah Newren" <newren@gmail.com>,
"Derrick Stolee" <stolee@gmail.com>,
"Phillip Wood" <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH RFC v3 2/2] Move libgit.a sources into separate "lib/" directory
Date: Tue, 11 Aug 2026 19:05:08 +0200 [thread overview]
Message-ID: <antWRHPHHES4a1KT@pks.im> (raw)
In-Reply-To: <xmqqpkzo39d2.fsf@gitster.g>
On Tue, Aug 11, 2026 at 09:33:29AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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
next prev parent reply other threads:[~2026-08-11 17:05 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:24 [PATCH RFC 0/2] Move libgit.a sources into separate "lib/" directory Patrick Steinhardt
2026-04-16 13:24 ` [PATCH RFC 1/2] t/helper: prepare "test-example-tap.c" for introduction of "lib/" Patrick Steinhardt
2026-04-16 13:24 ` [PATCH RFC 2/2] Move libgit.a sources into separate "lib/" directory Patrick Steinhardt
2026-04-17 17:08 ` Elijah Newren
2026-04-17 19:18 ` brian m. carlson
2026-04-17 21:18 ` Junio C Hamano
2026-04-17 21:51 ` brian m. carlson
2026-04-20 6:41 ` Patrick Steinhardt
2026-04-19 14:11 ` [PATCH RFC 0/2] " Phillip Wood
2026-04-20 6:41 ` Patrick Steinhardt
2026-04-20 12:03 ` Derrick Stolee
2026-04-21 5:55 ` Patrick Steinhardt
2026-04-21 14:13 ` Derrick Stolee
2026-04-22 6:39 ` Patrick Steinhardt
2026-06-22 10:38 ` [PATCH RFC v2 " Patrick Steinhardt
2026-06-22 10:38 ` [PATCH RFC v2 1/2] t/helper: prepare "test-example-tap.c" for introduction of "lib/" Patrick Steinhardt
2026-06-22 10:38 ` [PATCH RFC v2 2/2] Move libgit.a sources into separate "lib/" directory Patrick Steinhardt
2026-06-22 13:08 ` Junio C Hamano
2026-06-24 10:32 ` Patrick Steinhardt
2026-06-24 11:23 ` Oswald Buddenhagen
2026-06-26 16:01 ` Johannes Schindelin
2026-06-26 18:50 ` Junio C Hamano
2026-07-01 6:54 ` Patrick Steinhardt
2026-06-27 6:40 ` SZEDER Gábor
2026-07-01 6:55 ` Patrick Steinhardt
2026-07-01 13:26 ` Phillip Wood
2026-07-01 14:45 ` Junio C Hamano
2026-07-02 5:21 ` Patrick Steinhardt
2026-07-06 4:29 ` Kaartic Sivaraam
2026-07-01 6:59 ` [PATCH RFC v3 0/2] " Patrick Steinhardt
2026-07-01 6:59 ` [PATCH RFC v3 1/2] t/helper: prepare "test-example-tap.c" for introduction of "lib/" Patrick Steinhardt
2026-07-01 6:59 ` [PATCH RFC v3 2/2] Move libgit.a sources into separate "lib/" directory Patrick Steinhardt
2026-07-13 5:52 ` SZEDER Gábor
2026-07-20 14:24 ` Johannes Schindelin
2026-07-20 22:14 ` Junio C Hamano
2026-08-11 12:16 ` Patrick Steinhardt
2026-08-11 16:33 ` Junio C Hamano
2026-08-11 17:05 ` Patrick Steinhardt [this message]
2026-07-20 21:53 ` brian m. carlson
2026-07-20 22:43 ` Junio C Hamano
2026-07-20 23:40 ` Taylor Blau
2026-08-11 12:15 ` Patrick Steinhardt
2026-07-13 5:50 ` [PATCH RFC v4 0/2] " Patrick Steinhardt
2026-07-13 5:50 ` [PATCH RFC v4 1/2] t/helper: prepare "test-example-tap.c" for introduction of "lib/" Patrick Steinhardt
2026-07-13 5:50 ` [PATCH RFC v4 2/2] Move libgit.a sources into separate "lib/" directory Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=antWRHPHHES4a1KT@pks.im \
--to=ps@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox