Two Dimensional Version Control

During a summer Roguelike development event, I experimented with two-dimensional version control while writing a Roguelike game. My goal was to create a history of changes made while following the tutorial (horizontal axis) and the changes readers should make (vertical axis). I used Git branches, with each branch representing a chapter and pointing to the previous chapter as its parent.

This way, when I added changes to chapter 1, those changes were automatically pushed forward to chapters 2, 3, and so on. However, Jujutsu, a version control system, can do this automatically without managing branches and merges. I decided to try Jujutsu for this project, which would allow me to focus on the "writeup" column and edit any chapter at any time.

Jujutsu would then roll forward the changes from one chapter to the others. I used Jujutsu to improve the tile data structure while working on the dungeon generation chapter and found myself frequently going back and forth between chapters. I embraced the idea that commits were not set in stone but could be fixed if needed. Most of the changes were to the most recent chapters, but occasionally I went back and made improvements to earlier chapters, occasionally encountering merge conflicts.

To propagate changes both forwards and backwards, I used a combination of regular jj edit and jj absorb commands, but occasionally had to make certain changes manually to ensure the code compiled after the changes were made. I appreciated the ability to retrospectively improve version control change descriptions, as I spent time formatting them consistently.

Overall, Jujutsu proved to be a reasonable tool for this project, allowing me to develop the game while producing 50 intermediate versions with clean code for a tutorial series. The game was playable on the web, and I wrote notes but did not create a tutorial this time. I encouraged readers to reach out to me for any inquiries.