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