Devlog #00 — Building a Version Control System

With the advent of AI, Software Engineering has become increasingly more difficult for those earlier on in their careers. Traditionally, this was the time for juniors to learn, make mistakes, and hone our craft, but there's been a major focus shift in the industry towards more and more output. Because of AI, developers are expected to produce exponentially more than before, and often times, this means that we have less time to waste on learning the systems around us and end up shipping features that we don't completely understand. Worse even, we are being robbed of the opportunity to really think and solve problems on our own.

I've been working in the software industry for about double the time that AI has been commonplace, and the contrast between my experience before and after its introduction to the workplace is drastic. Before AI, I would be shipping less... but learning more. Solving problems without Claude and working out ways to build something on my own is something that I truly miss doing, and so, I figured "why not just learn something?"

Version Control

We all take git for granted. You'd be hard-pressed to find a software developer who hasn't at least heard of git; it's pretty essential when working on even moderately-sized projects. We usually don't stop to question its internals or why it's so fast and widely used as we type git commit 'rewrote entire codebase in Rust', but it's been something that I've always had a slight curiosity about, so over the weekend, I decided I would start building jit, my own distributed version control system, without AI.

I say distributed version control in the sense that each person carries a copy of the entire repository on their machine, but I'm not planning (at least not yet) on building any remote hosts for repositories made through jit.

The C Programming Language

The majority of the git core distribution is written in C, and I have terrible fond memories of C from my first-year computer science classes in university, so I decided that jit would also be written in C. What I loved about C was also what I hated about it; it gives you so much control over your computer (and especially memory), but this was a double-edged sword. The programmer was responsible for allocating memory whenever you needed dynamic allocation, and you had to remember to release those blocks when you were done using them. Not to mention the plethra of segmentation faults you would run into for seemingly no reason. It was frustrating; but at the same time, it was so exciting.

C is also great for learning things! Because it does basically nothing for you, the tools and infrastructure required for your project are yours to learn about and make. Almost nothing is abstracted for you, so it's the perfect medium through which developers can learn by doing. Need a linked list? Design the struct and implement the functions yourself.

A part of me was dreading all the work I would have to do for this project, but I was also excited. There was no pressure to do things quick, or to ship fast. I could really take my time and learn concepts fully before implementing them. Without AI, I would have to go through the struggle on my own, and experience the frustration of weird bugs coming out of nowhere, but it is in that struggle that we truly learn something.

Follow Along

Anyway, if you want to follow along, I'll be uploading devlogs whenever I reach a suitable checkpoint in my implementation with some of the things that I've learned. As a way to determine whether or not I've truly learned something, I'll be explaining the relevant concepts for each feature written about in that post.

I do want to note that I am by no means an expert on any of the topics that I may be writing about, and you should not treat my posts as a concrete source of truth, but I will do my best to make sure my explanations are accurate and informative.

Here's the repository that I'm working on.