Project LIT, short for Leo’s Git, will be my new project to write my own version control system (VCS). This project arises from a general interest in the internals of version control, a desire to learn Go and a love for solving problems in this domain. First, I will discuss potential differences one might consider when re-writing Git, followed by the next steps and a brief breakdown of what this might involve. The selected VCS features are based on personal preferences, without yet considering the design implications or compatibility requirements—those aspects will be addressed later. They also may change throughout the course of the project.

If I were to re-write Git

Currently, I am in the researching phase, looking into the internal mechanics of other popular version control systems – particularly the ubiquitous git, which will be what Lit will most resemble. A core design goal will be to reduce the learning curve for using a VCS with Lit. Here are some of the ideas I though may be helpful for a newcomer.

Single functionality, non-overlapping API

A narrow user interface with single functionality APIs which don’t overlap in use-cases will make a difference to the developer experience (at least I keep forgetting when I should be using reset, restore or checkout). This improvement addresses Git’s evolving use cases and API, which have since changed since its inception.

No Staging Area

For me, I find the common case in my workflow is to add changes to the staging area and commit at the same time. Removing the staging area also simplifies the tool for newcomers. Perhaps a –exclude parameter could be used to avoid committing files you don’t wish to commit.

Commit Stacks vs Pointers, an easier conceptual model

Looking at Meta’s custom source control Sapling also revealed some features that I would like to see in git if I were to re-write it – see here. A distinction that they make is that while a branch is a pointer to a commit hash, in Sapling a “branch” is a stack of commits. Sapling also provides a nicer stack view as the default command when nothing is specified, reducing the need for a complex conceptual model of what is required in your head. Some more thought is needed about how Lit should handle the “detached head state” and amending commits that aren’t at the head of a branch.

Undo command

An ‘undo’ feature would be invaluable for correcting erroneous commands. Implementing this would require each command to be reversible or maintaining a history of state changes. Further, undoing commands which push changes to remove may not be feasible.

Next steps

This project will involve the following components:

  • Data storage
  • Tracking Changes
  • Branching and Merging
  • Networking

My general approach will be to take these one by one, doing a little research and a very rough design before starting each component of the project. Throughout this project, I will code in Go to see what all the fuss is about. I will give a presentation on the internals of git at my work to other new starters. This will provide a good background, largely taken from this chapter of the git documentation.

Conclusion

This has been an initial discussion on the launch of project Lit, a version control system similar to git. This is a long-term personal project which I will work on in my spare time.