Always the same starting point: "I don't understand how git works".
If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope).
Abstracting this knowledge by using a tool that does things quite differently won't help you at all on the long run.
Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python.
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.
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
> 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.
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!
Unfortunately, I agree.
It is both ubiquitous and so unnecessarily complex. The fact that all developers are required to memorize at least a few of its inscrutable incantations reflects poorly on the industry and on the judgement of its practitioners.
Git is a bad teacher. There are a lot of things that are profound yet easy to grasp when learned and other things are called bad products. Git is one of them.
Moreover, you can use jj almost completely seamlessly with a git repo - including PRs etc to github. I do it daily and no one is the wiser.