4 ms·
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.
by umvi 1y 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"
- leipert 1y agoTotally 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)
- et1337 1y agoI 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.
- Izkata 1y agoWhich 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): git log --graph --oneline --decorate --all -100 I keep it as an alias, but it is annoying that seeing the whole structure is so hidden away.
- 1718627440 1y agoIsn't this the same graph, that every Git GUI program shows?
- stavros 1y agoYeah, 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.
- umvi 1y ago> 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?
- stavros 1y agoJj uses git's data model, that doesn't mean it uses git commands for everything under the hood. Creating a commit with jj doesn't move the branch tag automatically, whereas git does. That's what confused me with git, it didn't expose the internals enough, so even though I had read about the data structures, it never clicked what was changed when, because git did it under the hood.
- tcoff91 1y agoI 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.
- krackers 1y agoI'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.