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

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

On Fri, Oct 10, 2025 at 01:16:49AM +0200, Jörg Sonnenberger wrote:
> 
> On 10/9/25 1:46 AM, David Holland wrote:
> > 
> > It's a terrible model for development, and not even a good way to send
> > patches upstream to random projects.
> 
> It works OK for smaller contributions and projects that either have no
> strong opinion on style, commit message guide lines etc. or are willing to
> clean up those things themselves. It's terrible for actual development and
> made worse by the limitations of GitHub (and git).

GitHub allows hooks for many things.  Several projtects which accept
patches via pull include automated style checking and/or automated
testing before it gets looked at by a human.

> > Also, realistically, someone who can't manage to figure out a
> > different patch submission mechanism probably isn't going to be a very
> > successful contributor.
> 
> As someone who has tried to upstream hundreds of patches to as many
> projects, I want a low effort method. Just because I send you a fix for a
> problem, be it portability or even a bug fix, I don't want to have any
> significant attachment to your project. Having to sign up to a bug tracker
> for example is a no-go for that.

*This* is the advantage of GitHub.  Sign up once and you can submit
patches to thousands of projects without additional signups.  Perhaps
GitHub pull requests have limitations, but they seem to work well enough
for many projects the size of NetBSD.





On Thu, Oct 09, 2025 at 12:51:07AM -0700, Greg A. Woods wrote:
> At Wed, 8 Oct 2025 23:52:00 +0000, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 
> > But, to be fair, while tech-repository was created to sequester this
> > argument, that hasn't been super successful and some of the copies of
> > the argument are elsewhere.
> 
> Indeed!  I've read tech-repository in near real-time over the years,
> participating in some of the discussions and I've studied the archive of
> tech-repository and yet I've never found any really rational and
> technical discussion on these topics -- mostly just a bunch of repeated
> red herrings, personal preferences, unjustified claims, and similar.

The real situation seems to be Git and Mercurial are roughly on-par with
each other on the technical front.  There are zillions of differences
which make some people happy and some people unhappy.  Yet in the end
almost no projects (I know of none) needed to change between Git and
Mercurial due to technical limitations in either tool.

Everyone harps on Git not storing file rename information.  Yet in the
end it has turned out the rename detection strategies were good enough.
Mercurial lacks the ability to merge more than 2 branches at once.
Yet merging 3 or more branches doesn't happen very often and there are
simple workarounds.

Contrast this with the difference between the pairs CVS/Subversion and
Git/Mercurial.  Distributed version control has turned out to be
extremely valuable.  Since blaming is done locally you don't need to
worry about overloading a shared server.  These are vastly larger than
the Git vs Mercurial differences.

Since the technical differences are so small, the non-technical
differences are more important.


As has already been stated, by the time students have graduated more
than 90% of them have experienced Git and use it routinely.  Less than
1% of them will have encountered Mercurial, other than mentions.  People
with more experience may contribute more and better things, but that
should only go so far.

The real problem is network effects so strongly help Git now.  Until some
huge advantage beyond distributed version control shows up,  Git's lead
is insurmountable.  The best grouping for repository formats seems to be
"niche/disappearing repository formats" and "Git's repository format".


On Thu, Oct 09, 2025 at 12:51:07AM -0700, Greg A. Woods wrote:
> 
> Now don't get me wrong -- I don't really care what kind of repository
> the official NetBSD sources are managed with, and what the core NetBSD
> developers want to use to do that work, just so long as there's a way to
> use Git as a third-party to both access the source and to collaborate
> with NetBSD developers.  It could even stay in CVS if everyone promised,
> to stop messing with the CVS repository internals such that the hashes
> in the continuously migrated Git DAG were GUARANTEED to remain stable
> forever more.

To be truly stable, you'll need to wait for the move to the Git
repository format.  If stable for 2-5 years is good enough then waiting
for the move to Mercurial should be sufficient.  If you want stable in 10
years, you will need to wait for the Git transition.

The one trick is, why were shenanigans being done in CVS?  Similar
shenanigans are quite possible with Git and Mercurial, the term is
"rebasing".  The one trick is due to their peer-to-peer nature if enough
rebasing is done some prominent fork might take over...


-- 
(\___(\___(\______          --=> 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