Looks neat! This reminds me heavily of the excellent Building Git by James Coglan[1].
From a cursory glance though, it doesn't seem to support reading packfiles. This was the big thing that prevented me from using a fully custom Git implementation when I wrote my git churn calculator[2]. For larger repositories, it seems that almost all files are stored in packfiles, rather than the conceptually simpler "loose" format.
For me, the most valuable resource was reading the Git / libgit2 source and reference documentation.
Thanks! Note that ugit isn't supposed to be a custom compatible Git implementation, but rather a simplified Git-like implementation for teaching Git concepts. So even if ugit supported packfiles, it still won't be able to read a real Git repo.
It was custom made for the tutorial. I didn't release it yet because I mostly focused on polishing the tutorial itself and not the code for the interface. Do you think people would be interested in the interface by itself?
I was wondering the same, this format feels extremely intuitive for the material it explores. Looking at the HTML and the CSS class names I'd assume it was handmade, but it seems like standardizing this format or even generating this webpage format from a repo would be a useful tool. The comment left at the end is ambiguous as to whether it refers to the tutorial or the website as a whole.
> The real Git code is too complicated to be useful for learning basic concepts with ease. ... It deals with a lot of edge cases that we don't care about for learning.
Good choice, well explained. More than a toy problem space but stripped of factors that obscure the lesson. The author knows what they are doing.
Yes! I'm going to adopt that wording.
Originally I tried to do a screencast about guided Git source code exploration but it didn't work because of that reason.
This is a pure python implementation that started simple (just read a couple of files from the .git folder) but after a little I understood that for non trivial repos you'll need to deal with pack for files. Because I had already published the package I actually completed the pack parsing work but I have to confess that it's way too complex and I wouldn't have started the project if I knew better...
In any case the source is there if you want to take a look!
I believe this is a wonderful way for someone to learn a piece of technology in depth.
But I have to wonder if you actually had anyone (else!) successfully _use_ this to further their understanding of git?
Generally, for me, it's either myself doing the exercise unguided, reading the documentation on internals, or reading the original source code. So I am certain it was a huge benefit for you, but it's more of a question on the approach being used with "students" and how successful would it be?
I've seen people's Git skills improve after I taught them Git internals, but I taught them in a standard lecture format.
I didn't try teaching Git internals using code before, but I hypothesized it would be a good idea, and here is the result :) I'm curious about its effectiveness as well.
This is great, I appreciate the effort that has gone into it.
I have used git now for about 10 years, always via cli so I am pretty fluent with it and understand intuitively what is going on behind the scenes, but have only rarely needed to venture into the .git folders.
Working through the steps in this tutorial is helping to give a foundation to that intuition. I love the presentation format and would like to see more like this, and in other languages.
Is the tutorial itself available on github or elsewhere?
I definitely agree that having a good understanding of git's internals is a must for using it to its full potential. I'm not sure you have to go as far as implementing it yourself, but it is a sure fire way to get there. For me it didn't all click into place until I understood the data model behind git[1]. A git project is just one big DAG of objects, and each object at its core is either a blob, a tree, or a commit. When you understand that, you can start to view every git command for what they actually are, a sequence of operations on this data structure.
From a cursory glance though, it doesn't seem to support reading packfiles. This was the big thing that prevented me from using a fully custom Git implementation when I wrote my git churn calculator[2]. For larger repositories, it seems that almost all files are stored in packfiles, rather than the conceptually simpler "loose" format.
For me, the most valuable resource was reading the Git / libgit2 source and reference documentation.
[1] https://shop.jcoglan.com/building-git/
[2] https://github.com/samdoiron/butter