IMO its inspired by the best parts of git, hg, and darcs. jj split alone is worth the price of admission IMO

I haven't done a TON of scripted use of jj, but when I have the built in templating has come in clutch. If you want a command to return in a certain format (or include/exclude certain metadata) it's usually easier- and probably more future proof- to tweak the jj command's template than to parse the string in your script.

Not really, but it's a strong enough description that people who know what both are would understand

JJ is a whole new VCS, that just so happens to be backwards compatible with git, and currently uses git as it's storage engine

It builds atop the knowledge we gained since mercurial and git were both new, not making mistakes that the others made, as well as knowledge from newer VCS systems like fig and sapling

> Would it be accurate to describe Jujutsu as "a Mercurial-inspired frontend for Git"?

In my opinion: yes. (Maybe with a slight caveat that I think some of the Mercurial inspiration came through Sapling.) And it's not limited to Mercurial/Sapling ideas, it has some new stuff too, but I think that still counts as "Mercurial-inspired".

> Also, another question I have for people who have used Jujutsu: Is it focused on interactive use, or is it also convenient to use for automatic/non-interactive use?

I use it in automation. I'm hampered because the primary VCS for the automation is git, so I'm doing more of a compatible layer and can't go too crazy with the jj-specific stuff.

But jj has some features that are excellent for automation.

Example: you can manually wrap things in a discardable transaction: grab the current operation ID, do all kinds of weird mutating operations that add and remove patches, maybe even merge and rebase, and then at the end (maybe in a `finally` block) do `jj operation restore <id>` and everything will go back to the way it was.

Another example is that if you want to tweak something, say a config file, in N different ways, you don't have to mess around with naming branches and switching between them or whatever. Just create N independent child commits and make the appropriate changes in each.

Or conversely: make M children for the M values of configuration value 1 and N children for the N values of configuration value 2, then create a new multiparented child (a merge commit) for each combination. `jj new <a> <b>` creates a merge commit with parents <a> and <b>, so:

    jj new $base -m 'var1=a'
    jj new $base -m 'var1=b'
    jj new $base -m 'var2=x'
    jj new $base -m 'var2=y'
    jj new 'description("var1=a")' 'description("var2=x")' -m 'var1=a, var2=x'
    # run scenario 1 with those settings
    jj new 'description("var1=a")' 'description("var2=y")' -m 'var1=a, var2=y'
    # run scenario 2 with those settings

Sorry, I'm using the `description(...message...)` revset expression to retrieve the appropriate commits when in practice you'd probably record the IDs and do `jj new $a $x` with no descriptions anywhere. But hey, the above would work as written!

If I understand you correctly, then you can use `jj interdiff --from name-of-branch@remote --to name-of-branch@git` in order to recover the diff between the remote branch commit and your local version of it; you could then turn that invocation into a Git .patch file and reapply it with patch(1). This only works for one commit.

The more general solution you're looking for I guess is some kind of "split based on interdiff" or something like that. I don't believe there's any way to accomplish this in a single stroke, though.

I fixed this by changing the default immutable heads to include all remote bookmarks. This way, you cannot edit them and the new commit is automatically created when you push to the remote branch.

  [revset-aliases]
  "immutable_heads()" = "trunk() | tags() | remote_bookmarks()"

I also run into this often, I wonder if there is a simple built-in feature that would allow you to diff against the remote.

There's a few different ways to fix this, but here's what the official docs suggest: https://jj-vcs.github.io/jj/latest/FAQ/#i-accidentally-chang...

TL;DR - `jj evolog` and then restore changes from the relevant secret commit ID

Is `jj split` a good option?

I used to work on Sapling and Mercurial while at Facebook. I've been using Jujutsu full time for the last two years.

Jujutsu is in a sense the final form of that style of VCS, which I characterize as making commits first-class rather than branches, and providing powerful tools for managing long queues of stacked changes (git rebase -i is nice but has many limitations that don't exist in Jujutsu).

I go into some more detail in my testimonial, the first one at https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us....

I’d second Rain’s reply, but having gone from git to sapling to jujutsu, I feel like the jump from sapling to jujutsu was as big as the jump from git to sapling, in terms of “oh, this is a way nicer workflow”. I really like and miss Sapling’s interactive smart log, but I found jj’s conceptual simplicity to be more compelling than ISL. That said, VisualJJ and Jujutsu Kaizen (both listed on https://jj-vcs.github.io/jj/latest/community_tools/) might give you the ISL-style experience you’re looking for.

I'm mostly git -> mercurial -> sapling -> jj. For me, Mercurial -> Sapling was a mostly lateral, slightly upward move. Sapling -> jj felt really good, though oddly not because anything felt horribly wrong or missing in Sapling. Things just feel nicer and lighter in jj. Once I know a couple of things, I can combine them to do lots and lots of other things without learning any new commands. In fact, the total command set is pretty small, yet covers about the same range as other systems (a little more here, a little less there). Also, improvements come in at understandable and predictable places: at its current stage of development, it's not growing brand new commands. It is instead slightly improving existing commands to enable significant new capabilities. It has the feel of a well-designed system with mostly orthogonal components. (Give it a decade, and perhaps it'll start crumbling under its own weight too...)

This over-estimates the lock-in, because jj uses git under the hood. You can try jj, and your colleagues need never know. If you hate it after a couple weeks, you can return to git, no sweat.

It's much easier to try out than earlier VC systems.

One way (there are other ways to do some things):

`jj log` if needed to see what revision ID you need to use

`jj new <starting revision> -m <message>` to create a new change with a given message with <starting revision> as the parent. (you can also use the `--insert-before <revset>` and/or `--insert-after <revset>` to set the parent & child revison(s) for the new revision).

`jj bookmark set <feature 1 name> --revision <revset>` to make a bookmark (a branch name) on the revison you just made.

Make changes on this branch as desired. `jj new` for each new change you want to have its own revision.

If you added more revisions to the branch, `jj bookmark move <feature 1 name> --to '@'` (you can also use the change ID instead of '@', '@' just means "the current change you're editing").

`jj edit <starting revset>` to go back to your starting revset.

`jj new -m <message>` to make a new revset on top of the starting revset (the starting revset now has two children: it has branched)

`jj bookmark set <feature 2 name> --revision <revset>` to name the second branch you just created.

Make changes as desired. `jj new` for each new change you want to have its own revision.

If you added more revisions to the branch, `jj bookmark move <feature 2 name> --to '@'`.

`jj new <feature 1 name> <feature 2 name> -m "merge feature 1 & feature 2"` to make a new revision with the feature 1 & feature 2 bookmark revisions as its parents (this is a merge).

Alternatively, you could use `jj rebase` to move any number of commits to anywhere in the commit graph you want.

Here:

  $ jj new -m 'build my feature'
  $ touch my_feature.c
  $ jj new -m 'add some other feature'
  $ touch other_feature.c
  $ jj bookmark move main -t @
  $ jj git push

Replaces it entirely

Check out jjui. While it's not a 1:1 of lazygit, it's better in some ways and lacking in others, but quickly getting better. I really enjoy that it shows you the command every action runs under the hood. Great to expand your knowledge of JJ early on

There is a lazyjj but I don’t use lazygit so I can’t comment on how complete of an alternative it is.

Git is a content-addressable filesystem with a VCS interface on top of it. jj needs a content-addressable filesystem for a backend, and currently only uses git's implementation in released versions, but the devs are working on their own to serve as a "native" backend. At least in theory, just about any content-addressable filesystem could be used, e.g. IPFS, though many would not be efficient.

jj’s design is not constrained by git. git is one possible backend, but you don’t even need to use jj with git. I will eat a shoe if you can name something jj is prevented from doing by its relation to git.

You might be interested in pijul then, which has a theory of patches that is interesting.