[mamcx]

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands.

Now, I switched to `jj` a month ago and basically, I have learned around 60%-ish of it. And more importantly, I have gotten out of a bunch of serious trouble (you can UNDO!!!!) already.

But if this rant is not enough:

* You can UNDO. Everything. That is the major thing

* You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

* The command made sense

* Nobody else knows you use `jj`, so no barrier to adoption.

* Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

The major troubles:

* Not yet support for major tools, ides for it. It stays in `detached head` which is not as nice as showing the current branch on IDEs, and when you are fixing conflicts some tools do not get the diffs.

* No mature UI tool. I use `gg` which is fine enough

But the above is just temporal problems. Git will never be `fixed` or improved, so is pain forever.

[12_throw_away]

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions.

And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...

[pkulak]

I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see history, everything. There's almost no need for a dedicated plugin.

When I first started using jj, I remember just doing a "jj st" would commit everything and I'd lose all my editor support. It was pretty much the only part that got worse after switching. And now it's "fixed". If anyone knows more about jj than me, I'd love to know if I'm right about this, or just hallucinating. :D

[cube2222]

Can confirm this.

I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.

[pkulak]

Great idea! I just did this, and it's a very nice QOL improvement.

[tripple6]

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed.

> You can UNDO. Everything. That is the major thing

Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean.

> You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

> The command made sense

It's nice.

> Nobody else knows you use `jj`, so no barrier to adoption.

It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS?

> Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

[cube2222]

Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git.

> but does it work as a front-end tool over git/other VCS?

citing from the article

> Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend.

> I don't get it. What does make rebase hard?

It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1].

Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2].

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[1]: https://graphite.dev/

[2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[tripple6]

Regarding the rebase thing, I guess it's more a matter of habit. Stacked branches indeed may be tedious and may be annoying to rebase, agree. I implemented a shell script to rebase branch trees on top of a new base that would cover stacked branches as well. It covered all my needs like resolving conflicts, concluding or aborting the branch tree rebase and so on. Of course, it would be nice to have such a right-done thing right in git. But as of now, if I understand what jj is, it seems like I can shell-script some of its features myself. Still a happy git user.

[martinvonz]

I think the best way to answer most of your questions is just for you to try it yourself (https://jj-vcs.github.io/jj/latest/install-and-setup/).

> Everything is what?

Not interactions affecting remotes (you can't unpush a commit). Configuration is also not tracked. Neither are ignored files.

You can undo changes in the working copy, rebases, splits, squashes, etc.

> The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset.

Files added to the index can be recovered at least, but it's not easy to find them. The bigger problem is if you have not added them to the index and run e.g. `git reset --hard`. You can't undo that (via Git, but maybe via your IDE or your file system).

It's also about ease of use. I know you can undo a lot of things by using Git's reflogs, but it's not easy to e.g. undo a `git rebase --update-refs` that update many branches.

> I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

Yes, Jujutsu also supports that (`jj workspace`), but IMO, it's nice to not have to use them just because your working copy is dirty.

> What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode.

I've worked on the `git rebase` itself, so it's not like I don't know how to use it. Some things that I think are wrong with it:

* Without `--update-refs`, it only rebases a single branch. That's basically never what I want when I have branches pointing to other rebased commits.

* It's not able to rebase more than one head (no trees of commits)

* Doesn't rebase merge commits properly. Instead, it redoes the merge, discarding any conflict resolutions. (Yes, I know about rerere.)

> Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

Mostly that it's so stateful. While doing an interactive rebase (e.g. editing a commit), you're in a state where you can't easily check out another commit, for example. If you run into conflicts, you have to finish resolving all conflicts in the stack of commits, or you have to abort the whole rebase (throwing away any previous conflict resolutions).

Again, it will be easier to understand if you just try using Jujutsu for a few days.

[eikenberry]

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".

[pkulak]

> Nobody else knows you use `jj`, so no barrier to adoption.

All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D

[BeetleB]

You can name them if you want.

[zellyn]

Hah. I didn't even realize you could _not_ name them.

I just do:

    jj b c zellyn/appname-update-plugh-tests
    jj git push

[steveklabnik]

jj git push -c <changeid> will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.

[pkulak]

Oh, I didn't know you could do that. Nice.

EDIT: Docs here: https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix...