From: Taylor Blau <ttaylorr@openai.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
"Patrick Steinhardt" <ps@pks.im>,
git@vger.kernel.org, "Elijah Newren" <newren@gmail.com>,
"Derrick Stolee" <stolee@gmail.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Phillip Wood" <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH RFC v3 2/2] Move libgit.a sources into separate "lib/" directory
Date: Mon, 20 Jul 2026 18:40:57 -0500 [thread overview]
Message-ID: <al6yCTDjBRn2HGq0@com-79390> (raw)
In-Reply-To: <xmqqqzkx9t95.fsf@gitster.g>
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:
- "It is not obvious at all which files are part of "libgit.a" and
which files are only linked into our final executables."
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.
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.
So, I guess my feeling is that I am not closed off to the idea that the
benefits outweigh the risks/drawbacks here, but I currently do not see
that they do.
Thanks,
Taylor
next prev parent reply other threads:[~2026-07-20 23:41 UTC|newest]
Thread overview: 41+ 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-07-20 21:53 ` brian m. carlson
2026-07-20 22:43 ` Junio C Hamano
2026-07-20 23:40 ` Taylor Blau [this message]
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=al6yCTDjBRn2HGq0@com-79390 \
--to=ttaylorr@openai.com \
--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=ps@pks.im \
--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