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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 20, 2026, 21:53 UTC
Message-ID: <al6Yz_QMlyU1GETv@fruit.crustytoothpaste.net>
In-Reply-To: <20260701-pks-libgit-in-subdir-v3-2-5e4860056094@pks.im>

On 2026-07-01 at 06:59:27, Patrick Steinhardt wrote:

Show 14 quoted lines

> This move does not come for free though:
> 
>   - The mass rename introduces a cutoff point in the history of every
>     moved file, as tools like git-log(1) do not follow renames by
>     default.
> 
>   - Any in-flight or not-yet-submitted topic that touches the moved
>     files will have to be rebased, and backporting fixes across the
>     boundary becomes more cumbersome as a patch can no longer apply
>     cleanly to both the old and the new layout.
> 
> 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.

I agree this is worth it. I found it odd even when I started working on Git many years back that most of our code was placed directly in the repository root when most other projects put it under a directory. I think it would be valuable both for existing contributors and for new ones to tidy this up.

Show 6 quoted lines

> Furthermore, especially the first downside is a limitation in Git
> itself. We're not the first or last project to do such a mass rename. So
> if our provided tools are insufficient, then we should improve them to
> make the experience better for other projects, as well. Subjecting
> ourselves to the same pain may even give us more incentive to eventually
> improve rename following for everyone.

I would very much welcome better rename support and I'm sure the community would as well. If we can incentivize ourselves to step up and implement that, I'm all for it.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA