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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

Hi Gábor,

On Mon, 13 Jul 2026, SZEDER Gábor wrote:

> 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.

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.

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.

> > 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.

I am painfully reminded of all the arguments against migrating certain
repositories to Git. They sounded exactly like this.

> 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.

In case anyone was waiting for differing opinion, for a vote in favor of a
better structure of Git's source code, and of equipping the Git project
itself with the all-too-common need for improved support for following
mass-renames/moves across criss-cross merges, I am happy to provide.

Ciao,
Johannes