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

[Elliott Mitchell <ehem+netbsd%m5p.com@localhost>]

On Mon, Dec 22, 2025 at 10:10:34PM +0000, David Holland wrote:
> 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.

Well, this IS how it has to work.  It is impossible to prove it doesn't
occur.  Everyone here can state it has never caused problems for
themselves, but there are many other people for whom it could have
caused problems that we're unaware of.  Therefore as the person with a
provable situation you get asked to prove your claim.

You keep making claims of major problems with Git yet have provided
little evidence.  You gave an example, but it was trivially small.  We
need something much larger scale.

I also need to note the failure mode.  Git failed to complete the rebase
and indicated an error.  No data corruption, just git required manual
user intervention.  Certainly suboptimal, but that is far superior to
silent corruption.

For actually problematic behavior other systems can provide examples.
One such example of what BitKeeper would do:
https://marc.info/?l=git&m=114123702826251


> 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

Okay, you've made a claim.  Since you're claiming this occurs frequently,
please point to an actual instance.  Surely if this really does occur
frequently *some* open source project has had it occur, therefore it
should be easy to point to?

Then again merges tend to be a bit troublesome.  Until AI is good enough
to write programs there are going to be conflicts which humans have to
deal with.

Come to think of it, why are you placing so much emphasis on merges?
Since CVS doesn't allow merges, any merge handling is a major improvement
over the current situation.  I wouldn't expect there to *any* merging in
the present NetBSD workflow.


> 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

I see two distinct issues being incorrectly merged here.

First is the issue of transitioning from CVS to $other.

Second is the issue of which version-control system NetBSD should use
longer term.


I'm doubtful Git's rename handling strategy would actually be a problem
for the transition, but I could be wrong.  Since transitions are
delicate, perhaps Mercurial really should be used as a tool for handling
the transition?  Once those long-delayed renames are done switch to using
the Git repository as the primary?





I mentioned a point in passing and I think two people expressed doubt
about this claim.  I thought the overall situation was pretty clear, but
perhaps I should have explicitly addressed the issue then.  Better late
than never so some detail on Mercurial's future.

One metric for liveliness of a project is how many people are using it.
If surveys are done multiple times over the course of years you see
trends in things become more or less popular.  So some survey data of
professionals in software development over time:

                2015    2020
Git:            70%     90%
Mercurial:      6%      1%
Subversion:     20%     5%

I wasn't finding any survey data after 2022.  The trend is so clear
likely no one was willing to pay to ask on surveys.  So Mercurial usage
is well behind Subversion, which is rather older, less capable and slowly
retiring due to distributed systems being better.  I certainly wouldn't
advocate for Subversion since it appears to only be getting security
updates (no idea when security updates will end).

Ask any demographer or person in marketing what numbers like these mean.
Git usage is growing in both absolute and relative terms.  Marketing for
products focuses on 18-35 year olds since they become your clients now,
but are far less likely to change brands as they get older.  Git's share
appears to be greater amoung younger developers and lesser amoung older
developers.  Mercurial is the inverse which is the worst case for
long-term survival.

We should also look at what others have done.  One handy example is the
Xen Project, in 2006 they moved to Mercurial, yet 7 years later in 2013
they moved to Git.  Then we have Mozilla which moved to Mercurial in
2007, but then in 2023 was moved to Git.  Another is OpenJDK which as
part of Sun emulated Solaris and moved to Mercurial in 2007, yet in 2020
they moved to Git.  I'm unsure whether we should include Solaris
apparently converted to Git as part of turning into Illumos.

So we're drowning in examples of projects which have moved to Git.  There
has been a drop in reports of projects converting to Git in the past few
years.  This appears due to nearly every project already having moved to
Git.  We've also got several examples of projects moving from Mercurial
to Git.  Surely you can point to at least one example of a sizable
project which has moved off Git onto Mercurial?

Indeed, this is an argument to popularity.  Yet popularity is important
in the right circumstances.  Something which the transition to
peer-to-peer version control has made extremely clear is your first
criterion for choosing a modern version control system is the question,
"Can I communicate with other developers using this VCS?"  The answer for
Git is "yes", the answer for anything else is "yes if it can handle Git
data formats and protocol, no otherwise".



If you ask me for what I think Git's present situation is, I would
respond "Roughly akin to Sendmail's position in 1995".  The reason is
Git's position isn't nearly as stable as it may seem.  It is the
preeminent implementation of the Git storage format and network
protocols, but that is it.  This is similar to how in 1995 Sendmail was
the main implementation of SMTP.  History tells us what happened.  After
a few years there were many other SMTP implementations and while Sendmail
still exists, now it is far from being the most commonly used (E)SMTP
implementation.

If I wanted Mercurial to prosper the first thing I would make a priority
would be getting GitExtension on par with Mercurial's primary back-end.
This would let Mercurial behave the way you like locally.  While this
wouldn't be shared with other developers it would allow transparent
communication with Git users.

The next step would be to figure out how to embed Mercurial's extra
metadata into Git's repository format.  Greg A. Woods pointed to an
obvious approach to "named branches" on Oct 9, simply append a footer to
the commit message.  Explicit rename tracking would be more challenging,
but I see several potential approaches.

Peers which supportted the extra meta-data (Mercurial) would use and
update that data.  Peers which didn't support it (non-Mercurial) would
ignore the extra.  There would need to be a tool to synthesize the extra
meta-data when interacting with peers which didn't support it, but it
should be doable.

I don't see any other way for Mercurial to remain relevant.  Git's
repository format has an insurmountable lead.  Until something beyond
distributed/peer-to-peer version control shows up, the Git repository
format has won.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg%m5p.com@localhost  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445