Re: irt: Re: Core statement on version control systems

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

-- 
David A. Holland
dholland%netbsd.org@localhost