[oxceedo]

In the past 2 months, I saw 3 articles about JJ.

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.

[tcoff91]

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.

https://ofcr.se/jujutsu-merge-workflow/

[umvi]

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.

[tcoff91]

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.

[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!

[rob74]

Ok, I can get behind JFK's quote "We choose to go to the Moon not because it is easy, but because it is hard" - but do we have to apply the same quote to git? The way I see it, git is a tool and not a goal in and of itself. If there is a tool that does the same thing in an easier to use way (and can work with git repos), why use git? Of course, using VCS is part of the job description of almost every developer in the world, but git !== VCS...

[angiolillo]

> You MUST take the time to understand how it works properly.

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.

[mamcx]

"if some students fail the test, the problem is of the students, if many do, is of the teacher".

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.

[nchmy]

Are you writing everything in assembly? If not, your argument has no legs.

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.