[Exoristos]

One rarely needs more from git than `git add -A && git commit -m`.

[tcoff91]

I rebase stacked diffs all the time so jj makes my life so much easier because its rebasing is much more ergonomic than git.

[beanjuiceII]

this seems very easy in git tho how much easier can it get, do you have an example of each of them?

[rstuart4133]

As someone else said, jj comes into its own when a reviewer insists you split your PR into many commits, because they don't want to review 13k lines in one chunk. In that case it is easier because there is no rebase. To change a PR commit in the middle of the stack you checkout a PR commit, edit it - and done. The rebase happened automagically.

Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.

If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.

Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.

It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.

That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.

[mi_lk]

> That said, if you are starting out - I'd suggest starting with jj instead of git

That wouldn't be my advice if you're going to work with other people. You can't know jj without knowing git well enough to fall back in general

[dpatterbee]

Git rebases don't work if there are conflicts, jj doesn't have this problem. Also idk if you can rebase onto multiple parents with git but jj can do it.

[aidos]

Can you explain how conflicts are not conflicts?

If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?

[sunnyps]

JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/

[palata]

But what does that bring? Your code won't compile as long as you don't fix the conflicts, so anyway you have to fix them when you rebase, right?

[waisbrot]

That sounds like https://git-scm.com/book/en/v2/Git-Tools-Rerere ?

[account42]

I prefer `git commit --patch` and having a full editor for commit messages rather than a command-line -m argument to encourage me to actually write something useful.