[Skinney]

I find JJ to be what you get when you take a step back, evaluate everything that works in Git and try to find a design that accomplishes all those things with the fewest amount of concepts possible. Like a Git 2.0, if you will.

You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps.

Couple that with colocated repos, meaning I can use JJ while everyone keeps on using Git, there wasn't really anything holding me back.

[motorest]

> You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps.

Care to point out any concrete example?

[KingMob]

The entire chapter 2.4 "Undoing Things" in the Git book can be replaced with a single `jj undo`.

----

Anything to do with IDs is simpler, because a jj change ID is fixed at creation, even as the underlying current commit ID changes. This makes IDs useful even in a rebase-heavy environment.

----

Likewise, jj replaces the need for staging and stashes as completely separate concepts with their attendant extra commands. Anything you used them for is replaced with uniform commit/change commands: split/rebase/squash/etc.

Staging is just the current change; when you like the code you have, you make a new change, and the old one is just the parent commit. If you want to freeze part of it, you `jj split -i` the commit into a parent/child, and move the parts you're still working on to the child.

Stashes are WIP commits you leave lying around. If you want to move on to work on something later, you just `jj new some-other-commit`, and you're now on a blank commit whose parent is `some-other-commit`. When you want to resume work on that WIP, you `jj edit some-wip-commit` and/or `jj rebase` it first.

It's truly much simpler to have a bunch of pervasive change/commit operations, instead of superfluous ad hoc concepts with their own mini-commands and behaviors.

[motorest]

> The entire chapter 2.4 "Undoing Things" in the Git book can be replaced with a single `jj undo`.

Are you sure about that? Git reset doesn't need s chapter to explain.

Also, you should really pay attention to what you're writing. Your only tangible case in favor of JJ is user experience, and you even struggle to even explain what jj supposedly does, let alone how it's a preferable alternative. Even more baffling, this completely ignores the fact that the bulk of Git users use it through a GUI frontend, which completely negates any hypothetical selling point.

So, why bother with a solution for a problem you can't even clearly formulate?

[MrJohz]

> Are you sure about that? Git reset doesn't need s chapter to explain.

But it gets one — as they pointed out, Chapter 2.4 of the Git book (https://git-scm.com/book/id/v2/Git-Basics-Undoing-Things) is about undoing things. And to be clear, that's not just `git reset` — depending on what exactly you need to undo, you should use different tools, including amending existing commits and using `git checkout`. All of which will have different effects, and some of which can be dangerous if you misunderstand them (such as `git checkout` which can destroy data if you've not properly committed it yet).

Meanwhile, whatever the last thing you did with `jj` was, `jj undo` will undo it. On top of that `jj op log` will provide you a list of all the things you've done, and `jj op restore` can reset the entire repository to a previous state.

This isn't about UX: Git doesn't have the capability to do what JJ is doing here, because it doesn't track the evolution of the repository as a whole in the way that JJ does.

[GoblinSlayer]

I use git through a GUI frontend and it does the same things git does in the same way, like being unable to do most things without checkout, because cli needs this implicit context.

[Skinney]

Sure.

I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit.

In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.

In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change.

Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes.

To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.

[motorest]

> In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.

Not necessarily. You can just commit your changes, switch to whatever branch you want to work on, and then when you switch back to the old branch you can resume working as always.

This is not a Git thing. Even Mercurial advocated for this approach, and sold it as the only and true way of stashing changes. Mercurial only received support for a stash-like feature much later and in the form of an extension.

Also, even though git stash can be used in workflows that involve switching branches, it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch. Things like pulling changes from a remote branch or switching brsnched when you have random local changes in place (I.e., changed to config files for troubleshooting purposes)

[Skinney]

> Not necessarily. You can just commit your changes...

Saves me from doing that extra commit, then.

> [...] it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch.

That's also a thing I like about jj. Nothing prevents me from committing changes. Even merge conflicts are commited, so I know I can always come back to it later.

I find I think less about when to commit my work in jj. In Git I find that I like to commit to avoid loosing work, in addition to commiting when I feel "done" with part of a change.

It's a small thing, really, but it feels quite big (for me).