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.