On Tue, Dec 09, 2025 at 02:09:43PM -0600, Constantine A. Murenin wrote:
> But how come none of the other large projects have the renaming
> implementation as a deal-breaking issue?
I can think of any number of reasons that don't require that it's a
nonissue like you're trying to imply.
It's not like we're in an industry where technically unsound software
is never wildly successful.
Lots of people claim that the rename issue doesn't exist, does not
have the consequences it does, never occurs, doesn't cause problems in
practice when it does occur, etc. etc. etc. nobody saw me you can't
prove anything. The last step of this is demanding to know why it's
not exploding on everyone all the time, like you've just gotten to.
It does exist, and there are several reasons it doesn't get attention.
First is all those folks who insist it doesn't exist: most of them
aren't about to publicly change their minds. The second is that when
it does bite someone, they don't necessarily recognize the symptoms.
Most of the time, if someone gets weird merge conflicts they don't
understand, they give up or grumble and fix it up in longhand. Since
this will usually be happening to someone who _didn't_ do the rename,
and usually some time later, the causal link isn't obvious even if
they do look a bit. Then, also, many of the worst manifestations are
silent mismerges. When _that_ happens, by the time someone noticed,
it's impossible to figure out when or why. (Especially in git-fancier
land where rebasing all over the place has long destroyed the original
changesets.) And third, large renames aren't common. Most projects
don't spend large amounts of energy on long-term maintenance, and
because big reorganizations are invasive and disruptive they don't get
done often.
As I pointed out before, because CVS doesn't support renames at all
NetBSD has a large backlog of reorganizations to do; and, we do more
long-term maintenance work than most projects so we're more likely to
actually do them.
I find it ironic that it's claimed that those who claim that the rename issue doesn't exist, "aren't about to publicly change their minds", yet, effectively, we still don't even have a single cohesive document which expressly addresses all of the questions about this.
There have been several suggestions in this thread to expressly address the issue with renames — the config within git itself to disable the rename detections, and there's also Jujutsu (jj-vcs).
I believe it's unfair to the community that we're going into this without a proper cohesive explanation for the reasons why Mercurial instead of Git is chosen as the option, at a time when the tools we're choosing — both Mercurial and git-cinnabar — are effectively deprecated by nearly everyone else. Lack of a proper cohesive document, means that outside experts have little way to validate or critique our decision, or to provide any input on how to solve the issues we have identified.
Yes, it is very common that inferior solutions are more popular to the better-engineered ones. But I think in this case, the argument is a polar opposite fallacy. We're basically dismissing Git without even bothering to tell any Git maintainers about the rename issue being such a dealbreaker? Without any explanation or bug reports on why disabling the rename detection isn't an option?
I mean, the whole git rename detection is an extra feature, defaulting to `true`, but which can be turned off. Are we seriously dismissing Git simply because of an extra feature, which is set to true by default, but which can be turned off? I mean, if simply using a Mercurial backend, already effectively disables this feature within git, clearly it should be relatively easy to disable this even if Git itself is the backend?
Cheers,
Constantine.