The World Before Git

Unpopular opinion, but I still really like SVN and prefer Mercurial and Fossil to Git as distributed systems. You can install TortoiseSVN for a non-technical user and give them a quick rundown on how to checkout asset files from SVN, how to lock&#x2F;unlock it when they need it and when they are done and how to commit they can more or less understand it and work with it. GFL getting someone to understand how to use Git LFS or dealing with merge conflicts on asset files.<p>Git&#x27;s LFS&#x2F;annexe extensions are serviceable for developers and technical folks but really are subpar compared to a centralized version control options.

There are so many other industries where versioning is also an issue, but who lack the tools to properly manage it.<p>The start of my career was in the pro audio industry, where &quot;copy and rename&quot; mixing session project files is still a common practice:<p><pre><code> {songTitle}_final_rev2-2021.08.03-FINAL-MIX.ptx </code></pre> VCS working on text files allowing deltas&#x2F;diffs helps a lot in this sense, versus saving binary project files where diffs&#x2F;merges make little sense and can corrupt the output.

The world after git is jujutsu. Once you get your workflow down, it’s so much more useful than git because you can easily switch from any commit to another by editing it or checking it out, the latter creates a new commit on top of your working copy which itself is a commit. The former lets you amend.<p><a href="https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;v0.12.0&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;v0.12.0&#x2F;</a><p>You can squash your working copy into the previous commit with one command. All these things, to the uninitiated, probably don’t sound like much. All I can say is the UX is much more attuned to the way I work. Much quicker and more intuitive. It is exactly how I would build a vcs if I needed to and knew how.<p>I also like that it is built in rust. Since the vcs is really just a big data structure, I feel like rust is a good choice because of how it forces correct code to some degree and doesn’t allow cycles, etc.

&gt; ClearCase by Atria Software introduced a robust branching model, and the ability to configure workflows to the preferences of individual teams within enterprises.<p>Clearcase was awesome and terrible at the same time. Being able to version directories was somewhat novel then, so that was nice. Config specs - what a cool idea. Felt like a bunch of folks who had worked on filesystems&#x2F;NFS asked themselves &quot;hey what if we made a filesystem that could give a window into a VCS?&quot;. So cool, so compelling and yet so many devils in those details. At the time, things like clearmake and derived objects had such tremendous potential.

Well, git getting developed didn&#x27;t really do much to move people off Subversion: at the time, multiple DVCSes were being developed, like Mercurial, Bazaar (derived from Arch) and Git...<p>What got people to switch to Git (arguably, worst UX among them, but fastest for most operations) was GitHub combined with the rising popularity of Linux. But mostly GitHub.

Before Git, Perforce was state of the art.<p>Before that it was SVN (open source, decent) and tools like IBM Clearcase (not good, file locking, etc)<p>Perforce was very easy to use and honestly git was a step backwards on a overall usability.

i would like to insert a step 0, no version control whatsoever, which is what currently happens with the vast majority of VBA, and its top contender for replacement, Power Automate.

I remember downloading&#x2F;emailing patch files around and groaning when your local changes had made it impossible to get the patch file to work smoothly, so you ended up going through line by line trying to figure out what was supposed to go where, when...

Around 2003-2006 immediately before git (and mercurial) there were a bunch of new open source distributed VCSes. <a href="http:&#x2F;&#x2F;moinmo.in&#x2F;NewVCS" rel="nofollow noreferrer">http:&#x2F;&#x2F;moinmo.in&#x2F;NewVCS</a> lists a few of them from the time.<p>Bazaar, Bazaar-NG, Codeville, Darcs, Monotone<p>Git and Mercurial used ideas from a few of them and made them faster and more usable. For git it helped that there was a large project primed to switch to a new VCS.<p><a href="https:&#x2F;&#x2F;dwheeler.com&#x2F;essays&#x2F;scm.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;dwheeler.com&#x2F;essays&#x2F;scm.html</a> is another good source from that period<p>(disclosure I helped with Monotone a bit)

Right before git made it big, I got so fed up with SVN I decided to build my own.<p>It was UI based, hit a button and it would make a zip of just the files that had changed, along side an xml manifest of all files, their hash, permissions and metadata. Every so many commits it would make a full backup.<p>Worked really well, even built a visual difftool and history explorer - IMHO nicer than most git UIs these days.<p>No mechanism for branches or working with other devs but it worked really well for a small team working on a shared SMB server in 2007.<p>Thought about trying to commercialize it but git took off and I fell in love. Wrote a tool that converted that history to git and never looked back.

I suspect if only merit was involved, Fossil would be in more widespread use than Git.<p><a href="https:&#x2F;&#x2F;sqlite.org&#x2F;whynotgit.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;sqlite.org&#x2F;whynotgit.html</a>

The world before git had one thing that git lost: a strong notion of what &quot;upstream&quot; means. Git nowadays is used just like any other centralized SCM tool of lore; at the end of the day you push you changes to the master repo and go home. GitHub may have made git accessible and popular but it ironically did so by turning it into just another centralized SCM.

TFS and before that VSS were also major systems in use by companies. In TFS creating a new branch was a time consuming operation. But it did have one interesting feature which was the ability to exclusively check out a file. Interesting until that person left the company with the file still locked.

It&#x27;s kind of insane that we all just put up with the Git UX. It&#x27;s so bad, the author named it Git. But we all just keep using it as is.