[oxceedo]

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

[martinvonz]

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.

I just sent https://github.com/jj-vcs/jj/pull/7733 to provide some more detail in our "Git Comparison" doc.

[oxceedo]

Hi Martin,

We had somewhat the same exchange on reddit a few weeks ago under a similar article if you remember :)

Once again, I really appreciate the time you are taking to explain those things!

Everytime you chip in, it's always spot on and crystal clear. This is the kind of informations those people should put in their articles.

Have a good day and keep up the good work!