GoKawiilBeagle SCM
Beagle: git, URIs and all the dirty words
Human authored
Git's basic model is a wonderfully simple system of blob trees and commit chains that one can explain in 5 minutes to anyone. Further up the stack, that wonderful simplicity devolves into a mess of commands and flags developers with 20 years of git experience have difficulty remembering.
That is doubly so when multi-tasking with LLMs. "I believe we implemented it on Tuesday, but it is not here. Where is it?" "Which branch corresponds to that remote?" And so on.
If only we had some universal language to address and access local and remote resources, files and locations in files! Oh wait, we have HTTP and URI, which are as standard as it gets. Those were specifically designed for this task. Supported in so many apps and libs. Can we apply that to git?
Sure we can. Take GitHub URIs for example, they map the git space onto the HTTP URI space. The interesting part of this work is to define a set of orthogonal operations (a basis) so any git wizardry can be represented as a sequence of such steps, unambiguously, but no step can be represented as such a combo of other basic steps. The merge/rebase/cherrypick example will clarify this point later.
URIs
The URI layout we all remember by heart:
scheme: -- the access protocol / addressing scheme, //authority -- most often the network host, /path -- path in the remote filesystem, ?query -- other stuff (like arguments), #fragment -- location within the document.
... continue reading