First off I want to thank you very much for writing this and your other
recent reply!
At Sat, 29 Nov 2025 22:04:25 +0000, David Holland <dholland-tech%netbsd.org@localhost> wrote:
Subject: Re: irt: Re: Core statement on version control systems
>
> : Is there a publicly available rationale document?
>
> Rationale for moving away from CVS? The rationale for that is obvious.
Not a reason for doing so, but a "rationale". I think Andrew was asking
for something like what Warner wrote about the FreeBSD changeover to git.
> : Is [handling renames correctly] a real requirement?
>
> Yes, yes it is. The last time I got burned by git's "rename" support
> was, in fact, around the time this thread was happening. I moved some
> test reference outputs around at $WORK; then git got confused and
> created a confusing merge state that threw away some of the changes.
I think I understand much better about what you are "complaining" about
with Git's rename handling.
However you didn't really answer the direct question, i.e. is it a real
requirement for the NetBSD repository?
I agree with all the points you made about taking care around renaming
files and committing those changes. I would posit that they make sense
no matter how smart or dumb the VCS is. Much of what you say is echoed
here (and many other places):
https://www.codestudy.net/blog/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history/
https://gitscripts.com/git-mv
Also, Git's threshold for detecting file similarity can be controlled.
Even how diffs are shown and the algorithm used can be configured in a
myriad of ways, as is it possible to control how renames are handled on
merges.
diff.external
diff.renameLimit # default is 1000 files (also "git diff -l")
diff.renames # "false", "true", "copies"
merge.renameLimit
merge.renames
merge.directoryRenames
status.renameLimit
status.renames
I think Git is doing the right thing -- it is fundamentally tracking the
content of the files, nothing more, nothing less. The fact it can and
does try to guess about the history of files across renames is really
just icing on the cake that _can_ make the job of someone diving into
the history somewhat easier, but diving into deep history isn't usually
the main priority. It has many options, and it _is_ complicated, but
what one does with a length of rope is up to them.
Ideally I would hope NetBSD doesn't end up having any more massive
reorganisations of files and directories from now on. Such changes are
usually just some kind of bikeshedding in such a mature project.
On the other hand if reorganising files and directories is highly
desired then what does it really matter if the history of those files is
harder to follow? I.e. pick a priority and stick to it!
Any kind of handling of renames in the VCS is a feature over and above
what has been available for NetBSD with CVS, so, again, is Hg's way of
doing things a _strong_ requirement specifically for NetBSD?
> :: - storing the identity of long-running branches in the history
> :
> : Can you expand on this?
>
> In git, you can find the merge commit, and it has two ancestors, and
> there's a diamond in the commit graph. But you can't tell from the
> repository metadata which side of the diamond was the trunk and which
> was the development branch. You have to read and interpret the commit
> messages. You also can't tell which development branch it was.
I would just say that's what tags are for. :-)
Also it's trivial to embed the branch name into every commit message.
I find Git branches almost unusable without making branch base tags
anyway, so much so I'm thinking of figuring out how to automate it.
Tagging the head branch commit with a unique branch identifier tag
before merging it is also easy and useful and maybe even also
automatable.
--
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:
pgpB0g4AUrSq4.pgp
Description: OpenPGP Digital Signature