From: Patrick Steinhardt Date: Wed, 24 Jun 2026 10:32:18 GMT Subject: Re: [PATCH RFC v2 2/2] Move libgit.a sources into separate "lib/" directory Message-ID: In-Reply-To: On Mon, Jun 22, 2026 at 06:08:48AM -0700, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > The Git project is not exactly the easiest project to get started in: > > it's written in C and POSIX shell, with bits of Perl, Rust and other > > languages sprinkled into it. On top of that, the project has grown > > somewhat organically over time, making the codebase hard to navigate. > > > > But there is a rather practical problem: 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. > > Well, many things already live in the dedicated corner of their own > universe, like tests in t/, builtins in builtins/, and documentation > in Documentation/. This is pretty much moving everything else in a > single directory lib/. Surely there are things like top-level > Makefile and other build- and ci-related things that do not move to > lib/ for obvious reasons, but I view this move essentially to change > "for core-ish and library-ish things, look at the top level > directory" to "for core-ish and library-ish things look at lib/ > directory". Right. It does drown out the things that have to live in the root directory though, for example files like README.md or SECURITY.md. > Would that make it easier to navigate? I am not sure. What I am > sure is that this will force many in-flight topic (and soon to be > in-flight because people are holding them back during the prerelease > freeze period) to be updated, and it will make it harder to make > fixes that can apply both to 2.55 and before and newer codebase. That's definitely a downside, I agree. I have a bit of a different angle on the second part: it's not uncommon that projects move stuff around, and if Git cannot handle those scenarios well that's a usability issue that we'd ideally fix. And by doing such a rename we basically subject ourselves to the same pain that other projects are seeing, which might give us more incentive to actually fix those pain points. This might be a bit of a weird take and might raise some eyebrows. But it's basically a tooling issue, and we are the ones who provide the tooling. So we're in the best position to fix it, and by doing so make everyone elses lives easier, as well. Who knows how good submodules would have been nowadays if we had used them ourselves? :P > So, my initial reaction is somewhat negative, but I am known to > accept changes that I myself do not necessarily agree with, so... That's fair, and just to state the obvious: I'm still happy if the community decides that this is not worth doing. But from what I've seen until now it seems like most feedback I got was rather positive. Which honestly surprised me, I was expecting more pushback. Thanks! Patrick