That seems unnecessarily cryptic -- the whole HTTP analogy doesn't really work well, or the article doesn't do a good job of explaining it. I know, I come from a place of knowing git and beginners are often confused by it... but surely "checkout a branch, make a commit" has a clearer mental model than "post ?branch!", whatever that is supposed to mean.
Git vocabulary is workflow-based, i.e. "what we usually do". Unfortunately, the language grew complex and easy to mess up. The problem of NxN interactions: what happens if we do C between A and B?
So the idea here is to define actual operations that happen to the tree, formally. Those are a bit more complicated than the vanilla blob/tree/commit model, but still manageable. Six verbs is enough.
Overall, it all decomposes cleanly and uniformly. Workflow-based vocabulary becomes unnecessary (and a bit confusing) once you grasp that basic underlying model of orthogonal operations/concerns. Some parts still need work though, e.g. conveying the precise state of the tree (can't steal from git here).
Agreed. I think the code examples in the article could do with showing before and after states of the branch or repo and maybe compare with standard git commands.
Even then I don't think the abstraction to HTTP verbs is necessarily a useful one as web requests and version control are two different mental models.
I love the idea of building a new Git UI on top of Git primitives[1], but the REST inspiration leaves me feeling underwhelmed; there has to be a more human-friendly model.
The most human-friendly thing is probably natural language. If so, it is LLMs who should have an intuition about the REST interface and its URI syntax. I personally would prefer to glance at it, but not to type it repeatedly. Especially, hashes.
So, the actual question is how to make this machinery un-screw-up-able. (Author)
It doesn't use Git primitives directly, but it has Git interoperability using semantically more powerful primitives. (e.g., there is not only one index -- you can perform rebases, amends, squashes etc. remotely (without checking out first) -- conflicts are non-blocking and support n-way merges -- and so much more)
I've embraced it to the point of porting complex agentic frameworks to support jj (https://github.com/LoganDark/get-shit-done) and I do not regret it at all. Jujutsu is my absolute favorite VCS now.
That seems unnecessarily cryptic -- the whole HTTP analogy doesn't really work well, or the article doesn't do a good job of explaining it. I know, I come from a place of knowing git and beginners are often confused by it... but surely "checkout a branch, make a commit" has a clearer mental model than "post ?branch!", whatever that is supposed to mean.
Git vocabulary is workflow-based, i.e. "what we usually do". Unfortunately, the language grew complex and easy to mess up. The problem of NxN interactions: what happens if we do C between A and B?
So the idea here is to define actual operations that happen to the tree, formally. Those are a bit more complicated than the vanilla blob/tree/commit model, but still manageable. Six verbs is enough.
Overall, it all decomposes cleanly and uniformly. Workflow-based vocabulary becomes unnecessary (and a bit confusing) once you grasp that basic underlying model of orthogonal operations/concerns. Some parts still need work though, e.g. conveying the precise state of the tree (can't steal from git here).
Agreed. I think the code examples in the article could do with showing before and after states of the branch or repo and maybe compare with standard git commands.
Even then I don't think the abstraction to HTTP verbs is necessarily a useful one as web requests and version control are two different mental models.
I love the idea of building a new Git UI on top of Git primitives[1], but the REST inspiration leaves me feeling underwhelmed; there has to be a more human-friendly model.
[1] https://replicated.wiki/wiki/Home.html
The most human-friendly thing is probably natural language. If so, it is LLMs who should have an intuition about the REST interface and its URI syntax. I personally would prefer to glance at it, but not to type it repeatedly. Especially, hashes.
So, the actual question is how to make this machinery un-screw-up-able. (Author)
> the REST inspiration leaves me feeling underwhelmed; there has to be a more human-friendly model.
Jujutsu VCS! https://www.jj-vcs.dev
It doesn't use Git primitives directly, but it has Git interoperability using semantically more powerful primitives. (e.g., there is not only one index -- you can perform rebases, amends, squashes etc. remotely (without checking out first) -- conflicts are non-blocking and support n-way merges -- and so much more)
I've embraced it to the point of porting complex agentic frameworks to support jj (https://github.com/LoganDark/get-shit-done) and I do not regret it at all. Jujutsu is my absolute favorite VCS now.
I admire any attempt to simplify Git. I'm less convinced that making it look like HTTP is the simplification people were asking for
"yo dawg, I heard you like confusing SVC CLIs" vibes