I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools.
Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python.
Well then articles should focus on that if they want to convince people who use git as a daily driver. Currently the impression I get from jj is that it's "git for people who have a hard time understanding/using git", therefore since I don't have a hard time understanding/using git, jj is not for me.
Maybe more articles showing galaxy brain SCM workflows that are difficult under git but possible under jj and are killer for productivity is a better marketing strategy for jj.
I wholeheartedly agree with you. What makes jj a killer app to me is that it allows me to work with source control in a whole new way that just feels so much more powerful to me. I haven't felt like this since I first discovered git after dealing with the pain of subversion.
Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git.
Which every articles I read on JJ failed to do correctly.
My point is not to avoid using other tools to do your job. My point is that if you don't understand something, using a layer on top of it won't help you at all understand things in the long run.
I want to see JJ articles made by Git experts; not JJ articles made by people who fear Git lol
FWIW, Drew DeVault wrote such an article but he later took it down (in protest of the Google CLA, I think). You can probably still find it somewhere.
> Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git.
I'm not the person you asked but I can try to explain (I started the jj project, fwiw). Some things `jj rebase` does better than `git rebase`:
* It rebases whole trees/graphs of commits. This is the scenario described at https://stackoverflow.com/questions/17315285/rebasing-a-tree.... Bookmarks/branches are always updated accordingly. `git rebase --update-refs` can do that these days, but still only for one range of commits at a time (i.e. one leaf commit).
* It lets you rip out some commits of a stack and put them somewhere else. This is the `-r` flag. See https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase for some examples. You can also reorder commits by doing things like `jj rebase -r X::Y --insert-after Z` to insert the range of commits from X though Y after commit Z. You can parallelize parts of the graph by doing e.g. `jj rebase -r C --insert-after A --insert-before D` to take an initial linear graph A..D and make C parallel to B.
* It doesn't stop when there are conflicts. You can instead resolve the conflicts when you feel like it.
* It's able to rebase merge commits well, even if there are conflicts and/or conflict resolutions in them. `git rebase --rebase-merges` with the "ort" merge strategy and rerere enabled gets close these days.
* It's about 100x faster by not touching the working copy unnecessarily. `git replay` also does that.
Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python.
https://ofcr.se/jujutsu-merge-workflow/