Hacker News Reader

Comment by umvi | Hacker News Reader

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"

View on HN

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.

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):

  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.

Isn't this the same graph, that every Git GUI program shows?

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?

Jj 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.

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)

Reply on news.ycombinator.com