Comment by umvi
4 months ago
I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article.
Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph.
If you use this mental model, suddenly things like git rebase or git reset become far less mysterious and arcane since they are just simple graph operations. Like `git reset --hard X` means "Make current branch's text pointer point to X"
I think the author is one of those folks who were able to fully grasp the beauty of the Git data model for the first time by switching to Jujutsu. It makes it easier to see the “DAG of commits” vision than Git with its index and stashes and confusingly named commands with fifty flags.
Yeah, exactly, and I've fruitlessly read too many guides on git's data model.
What was holding me back turned out to be the fact that git has too much magic (it updates branches automatically when you commit, rebasing "does stuff", conflict resolution was just arcane).
Jj exposes all that into simple, composable principles, making everything click.
> What was holding me back turned out to be the fact that git has too much magic
Considering jj is built on top of git, doesn't that mean jj has even more magic? That's like saying React is too magical so we should use Next.js instead (which is built on React).
Maybe you just mean that jj has a more intuitive CLI than git?
1 reply →
Which is why I always make sure to show that graph to co-workers new to git (we have a lot of code still on svn):
I keep it as an alias, but it is annoying that seeing the whole structure is so hidden away.
Isn't this the same graph, that every Git GUI program shows?
I understand git at a pretty deep level. I still very much prefer jujutsu. Its rebase is just so much more powerful than git. I regularly work on top of octopus merges in jj of all my in-review parallel PRs and when I want to rebase them all and the octopus merge and the various anonymous branches on top it takes 1 command. It’s so much more powerful than git it’s crazy.
I've seen this before and I still don't understand. Unless jj comes with some magical conflict resolver, you aren't avoiding the hard part which is merge conflicts. At best you can defer them until you need to deal with them later.
Totally agree on the DAG point of view, but I would argue that for different people you need different analogies/models to make it click. I would argue that pointing towards graph theory might help people that have a formal CS or maths education, but not necessarily folks that went through bootcamps, switched from design roles, have a biology background (e.g. bioinformatics) or do statistics (e.g. in medicine or psychology)