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

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Wed, Jul 01, 2026 at 08:59:27AM +0200, Patrick Steinhardt wrote:
> 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.

It is not a one-time cost, but will be an ongoing burden.

> 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'm uncertain how that should work, and rather sceptical that it would
work at all.

Some have expressed that it is a pain to deal with the fallout of this
patch.  Should we then come up with those envisioned improvements,
whatever they might be?  I'm fairly certain that I won't have the time
for that.  Or should you do those improvements, because, after all,
you thrust upon us this churn?  Then it would certainly be better to
come up with those improvements first...

Overall, I remain unconvinced, and maintain that this just trades one
annoyance for the other, and it's not worth it.