In order to understand this story, we'll need an appropriate mental
model of Git. At their core,
version control systems save previous states of a project. That way
programmers can wind back time to figure out how bugs were
introduced. An analogy could be recording a chess game so that
interested observers could analyze important moves. Take, for
instance, Deep Blue versus Kasparov, 1997, Game
6.
I’m interested to see where this story goes! Just for the banter, the general problem (versioning system for documents) is one I’ve been interested in for a long time.
As that link will show, I’ve recently become a devotee of Fossil. It shares much with Git (it is possible—with certain limitations—to move between them, or to mirror a Fossil repo in Git), but differs in significant ways as well.
I’m wondering how this story (as it eventually unfolds!) might have looked different with Fossil as the main character rather than Git. Be that as it may, I’m looking forward to the next installment!
" There are a lot of great things about Git, but one feature that can cause issues is the fact that a git clone downloads the entire history of the project, including every version of every file"
That isn’t exactly true. We currently have a rather mismanaged, monolithic repository across multiple teams, that’s about 4gb, and downloaded via a very creeky VPN, from an even creakier server.
One of the things those in the know do is set a shallow clone - with say --depth 1 (or 10). You can then ‘deepen’ the git clone at leisure, and not download as much in a single time.
This cuts down the download to ~200mb, about… 10mb of which I actually need.
The next installment will be about GitHub Actions. I’m not sure if there is a Fossil equivalent. GitHub seems like a big reason for Git’s popularity to be honest.