Exercises like this are very educational for taking magic away from version control tools.
Some time ago I did a similar exercise in Haskell: https://github.com/EarlGray/omit (it also took about 500 lines of unnecessarily dense Haskell), implementing barebone functionality of `git log`, `git add`, `git commit`, `git status`, `git diff` (using an existing Haskell diff library). It was eye-opening how simple the concepts of git are.
On the other hand, the most interesting parts of git are still left out: branches, merges, conflict resolution, remote sync. I'm wondering how many more lines are needed for this.
> It was eye-opening how simple the concepts of git are.
Exactly! Sometimes I'm bewildered how complex git porcelain (CLI interface) is compared to the basic building blocks.
Usually when I want to do something complex in git I think of how I want the structure to look like and then figure out which command does that ("was it git reset --soft or git stash --keep-index that did X?"). Now when I'm thinking about it I usually imagine states (like DOM trees). I see current state and the state I want to have the repo in (commits, working directly, index). What I'm missing here is a React-like reconciler that will transform one into other.
The thing is, all of these details are implemented in the git command line tool, not in a library. So it is pretty difficult to write a tool that works exactly the same way the command line tool does, or if you do manage to do it, it'll be fragile since the command line tool could change behavior at any time.
I love projects like this, because I think most of us would benefit from re-implementing our dev tools (at least partially) to develop a better understanding of how they work.
Traditionally some of the trade apprenticeships started with the new apprentice making their own tools.
When I took a molecular cell biology class in college, the first series of labs involved disassembling and reassembling the bench microscopes that we would be using for the rest of the course (they were close to maxing out on optical resolution, the faculty couldn't afford to replace a broken one)
As an engineer I enjoy making my own tools, sometimes a little too much
Similarly, when I got my first job as a PC tech at a locally-owned computer shop, my first task was to assemble my own "bench" PC for testing various components.
More in that vein, for Python bytecode compiling and running: https://github.com/darius/tailbiter -- I can't quite resist mentioning it since I gave it a similar tag line, "just enough Python to Python in Python".
I hope this isn't taken as a frivolous or mean-spirited comment, but the code samples on the blog would be much more readable with some kind of syntax highlighting.
I don't think it would be of any strategic advantage? The promise of Rust is to be once better than C not better than Python. Nit to mention all the needed libraries.
I'm a bit confused by this logic; git is written in C, so if Rust is supposed to be "better then C", then wouldn't it make perfect sense to write it in Rust?
In general yes, it would benefit Rust, long term. But for the purpose of this article, no. The result would at this moment be much bigger than 500 lines, which wouldn't have any power of a short example.
Some time ago I did a similar exercise in Haskell: https://github.com/EarlGray/omit (it also took about 500 lines of unnecessarily dense Haskell), implementing barebone functionality of `git log`, `git add`, `git commit`, `git status`, `git diff` (using an existing Haskell diff library). It was eye-opening how simple the concepts of git are.
On the other hand, the most interesting parts of git are still left out: branches, merges, conflict resolution, remote sync. I'm wondering how many more lines are needed for this.