I have seen Larry make similar claims about the weave format vs. patch-based format many times, and he has also put git firmly in the "patch-based" camp, but I believe the only real effect to git not using a weave is increased time-complexity of "blame" operations.
1. Git has constant time access any version of a file as well; the --depth option to the pack algorithm places a constant (but configurable) upper bound on the number of deltas that will need to be applied whenever fetching a blob. Intuitively, it would seem to me that for files with extremely large numbers of changes, this could be faster than extracting the weave, potentially at reduced space efficiency.
2. Merges are separate from the commits that effect the change; the lm/clem example in TFA would work as expected on git. Merge commits will only show up in the annotation if there were conflicts.
When I took over Cambridge University’s DNS, its code and configuration was still in SCCS, because that was what shipped with SunOS in 1991ish. I converted the SCCS archive via RCS and CVS to git – https://dotat.at/@/2014-11-27-uplift-from-sccs-to-git.html – which was a fairly entertaining exercise. (Sadly the links in that blog post are mostly broken.) I even used those conversion scripts more than once! https://dotat.at/@/2016-07-19-uplift-from-sccs-to-git-again.... (That repository ended up with at least three distinct root commits, one for the main DNS history, one for the Ansible setup that started with DHCP and later grew to handle DNS too, and later the separate vanity domain DNS setup.)
* https://en.wikipedia.org/wiki/Ancient_UNIX#The_Unix_Heritage...
The source code itself was moved to Subversion (via RCS and CVS) long ago, and later to Git, but the configuration files continue to be tracked using SCCS.
There is an open source implementation of SCCS called GNU CSSC: https://www.gnu.org/software/cssc/
We could migrate it all to Git, but unlike with source code, we do not branch or merge config, and there are no clear benefits to a migration to justify the effort and the risk.
Looking through the rest of the archive, nice to see that Larry has gone into retirement but makes time away from fishing to continue to tell us how fucking smart he is and how stupid everyone else is. Never change, Larry.
I finally found out the probelem, which was part sccs and part xenix.
xenix had shorter filenames, so while checking filename.c into SCCS gave s.filename.c, checking longfilename.c into sccs gave s.longfilename and checking it out lost the .c extension and make wouldn't compile it.
https://web.archive.org/web/20241213205017/https://www.tuhs....