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

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

On Tue, Dec 23, 2025 at 11:36:43AM -0600, Constantine A. Murenin wrote:
 > 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.

Would you like to write one? I agree it would be a nice thing to have.
The trouble is, it takes time and effort. And, as I've already said
several times, this same flamewar has been happening over and over
again for years and years and it's tiring.

This is the pattern:

-> A wild GIT ADVOCATE appears!

<- . o O ( oh no, not again )

-> Why aren't you using git?

<- Git has these design flaws and the user interface is a trainwreck.

-> Impossible! Git is perfect. Why, I use it myself.

<- Git has these design flaws and the user interface is a trainwreck.

-> Git is *distributed*. You have to understand distributed version
   control.

<- Yes, we understand distributed version control. That's why we can
   point to these design flaws. And, the user interface is a
   trainwreck.

-> There are no such problems.

<- Git does actually have these design flaws, and the user interface is
   a trainwreck.

-> You're wrong, those issues don't exist.

<- Alas, we aren't. Git does actually have these design flaws and the
   user interface is a trainwreck.

-> You're wrong to want to do that. Change your work style. Then it
   doesn't matter.

<- Why should we change our procedures to work around problems in your
   tool? Anyway, Git has these design flaws. And the user interface is
   a trainwreck.

-> Those aren't problems. It works fine. Why, I use it myself.

<- Unfortunately, it doesn't. They're design flaws, you can't really
   escape them. And the user interface is a trainwreck.

-> You can work around it like this. Just (disable this other feature,
   change your work style, etc.)

<- They're design flaws, you can't really escape them. And the user
   interface is a trainwreck.

-> Well, maybe you have a point about the user interface. But just use
   a porcelain.

<- That doesn't fix the design flaws.

-> Everyone else uses it! Why do you think you're so special?

<- Everyone used to use Windows 98, too. Don't blame us because you
   never bothered to learn any better tools.

-> GIT ADVOCATE uses FUD.
   It is not very successful!

<- ...


The current thread may not have touched quite all these points yet,
but it's hit most of them.

Also, I'm getting yelled at off-list for continuing to respond, so
this is going to be the last post.


 > disable the rename detections

Disabling git's rename support entirely reverts to the status quo of
CVS not supporting rename. That isn't helpful.

Ultimately, the design flaw is that git doesn't store rename metadata,
and you can't really work around it.

 > there's also Jujutsu (jj-vcs).

That seems to be a whole different (and newish) tool. (That is, it
seems to be more than just another git porcelain.) I'm not optimistic
because it still seems to be a wrapper around git, and you can't fix
git's fundamental design flaws that way. (Also I'm a little concerned
by the section in the project readme that talks about replication as
if distributed version control doesn't already do that.)

But also, it says it's experimental. It might be interesting to
experiment with. Doesn't look ready to adopt.

(https://github.com/jj-vcs/jj for the curious)

 > outside experts

Who do you propose as outside experts who would have anything useful
to add? Keep in mind that version control is a storage application,
and NetBSD, being an OS project, has a lot of institutional experience
with storage and a lot of community members with a lot of experience
with storage.

Also, we've had any number of git advocates with no apparent ties to
the NetBSD community walk in and read from the script above.

 > tell any Git maintainers about the rename issue

The git maintainers have also had some twenty years to fix their shit.
It's implausible that they don't know about the issue. (It's also
unlikely that they care specifically about any given user considering
it a dealbreaker.) There's also been ample time, in the course of all
the iterations of the argument outlined above, for someone interested
to take it upstream. Since nothing's changed, reasonable explanations
include:

   - like the typical git advocate, the git maintainers deny that
     there's a problem and won't accept arguments to the contrary;

   - the git maintainers recognize that there's a problem but don't
     consider it important;

   - the git maintainers recognize that there's a problem but it's
     unfixable for whatever reason (perhaps compatibility).

 > I mean, if simply using a Mercurial backend, already effectively
 > disables this feature within git

Anything follows from an invalid premise!

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