Rewriting a Git repository

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.

This is a companion discussion topic for the original entry at

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.

Oh yes. I leaned about shallow clones since it was sometimes impossible to clone otherwise.