At Wed, 8 Oct 2025 23:52:00 +0000, David Holland <dholland-tech%netbsd.org@localhost> wrote: Subject: Re: irt: Re: Core statement on version control systems > > Well, for starters you might try looking at the mailing list archive > and not some random decade-old wiki page. It's not just some "wiki page" -- it's wiki.NetBSD.org. Most readers have no idea if or whether or where there might be something more authoritative elsewhere within the NetBSD.org domain. If we stumble on something that's out of date on a NetBSD.org site, despite giving no outside indication of such, then that's not our fault -- that's the NetBSD Project's fault. > 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. 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. > > Also, how does Hg fits the requirements at the top of that page better > > than Git? > > That list is missing at least two critical points where git falls > short: And I think both of them are really just red herrings -- they certainly not critical show-stopper shortcomings! > - storing file rename data So to describe this issue in slightly more detail: Mercurial uses rename tracking (where you have to tell it explicitly to rename your files for you), while Git uses rename detection to deal with file renames that have happened since the last commit with normal cp/mv/rm commands. Why bother having to tell the VCS what you're doing -- why not just have the VCS figure it out from what you've done? I don't think it really matters in the end when the file contents make it quite clear what happened, especially since both VCS' allow the same method of "following" code to see diffs across renames. Note too that Git's auto-detection also works to find code that's been copied wholesale between files even without a rename, potentially even at a finer grain than the whole file too. Then there's the thorny issue of historical file renames. Unfortunately NetBSD's CVS repository has suffered numerous abuses over the years, some where files were even renamed in the repository. None of that will really be recoverable with Hg so far as I can see, at least not without detailed reconstruction of those "crimes", and some extraordinary extra effort being applied to work that unrecorded history into the conversion process. Meanwhile with Git this rename tracking might just be automatically recoverable since Git tracks all the _contents_ of all of a project's files simultaneously across points in time, > - storing the identity of long-running branches in the history Some people apparently call Hg's "named" branches "commit labels" because that's what they appear as in the logs. Where and what exactly would the benefits be to the NetBSD project of having the branch "identity" stored as metadata in each commit? How and when and where would you forsee this information being used in the NetBSD project in particular? What if commits happen on semi-long-running (but still "named" in hg parlance) branches and then are ultimately merged to some other longer-running branch? In Git commits can "belong" to different branches over their lifetime, e.g. as they get merged, and I think this is a good thing. Why just for long-running branches? As far as I can tell none of the ancient history of NetBSD converted from CVS will have accurate branch metadata in each Hg commit, especially from merged branches anyway -- it's all just 'trunk", no? (at the moment I can't check as I can't even 'hg clone' NetBSD any more -- something on the server side is prepending an extra "https://"; to the front of the name of the clone bundle) Going forward with Git it would be trivial to arrange to have the current branch name automatically edited into every commit message template (and even verified that it's still there upon commit). -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpQMXHHFjn2M.pgp
Description: OpenPGP Digital Signature