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

On Mon, Jul 20, 2026 at 03:14:24PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <[email protected]> writes:
> 
> >> > My own (obviously subjective and biased) take is that the tradeoff is
> >> > worth it, as these issues are a one-time cost while the benefits to
> >> > discoverability will be permanent.
> >> 
> >> It is not a one-time cost, but will be an ongoing burden.
> >
> > It is maybe drawn-out, but it is a one-time cost. It's not like we're
> > going to mass-rename source files to move them to `lib/` every two weeks
> > from now on.
> 
> Since the topic was posted, I have dealt with the fallout from it at
> least twice a day (which, when we are lucky, is not a huge time
> sink, as I have mostly automated it by now), and again every time a
> new topic is posted that touches the moved files in substantial ways
> or adds new files that ought to be moved.  The latter is the most
> time-consuming to handle.  This will continue until all contemporary
> topics, as well as the topic in question, graduate.
> 
> If that is not an ongoing burden, I do not know what is.

I guess the argument is rather that it's a burden now, but once it's
merged and the dust has settled it's going to become less so.

> > And this statement neglects to acknowledge that the lack of clean
> > organization of source code files is an ongoing burden _right now_, and
> > would be at least partially addressed by the move.
> 
> At least, Gábor does not seem to think that the lack of clean
> organization is so severe as to warrant a massive code churn like
> this.
> 
> I value stability much more than prettiness.  If we had started out
> with almost nothing at the root level and almost everything in
> either 'lib' or 'builtin', I would have strongly preferred to keep
> that structure.  But since we have been using a layout that has all
> 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.

So I'd say main motivation isn't prettiness, it's discoverability. And
sure, that's a property that regulars on the mailing list are unlikely
to care about as they already know their way around the project. But I'm
sure that folks who are new would appreciate it if they could see at a
glance what parts the project is made of to help them find the right
files at the right time.

Anyway, as I've said already: I'm totally fine if the result of this
discussion is that we don't want to do it. It is churn, and that churn
has of course does have a cost.

Thanks!

Patrick