I don't get JJ. Every time it's posted people gush about how JJ enables some super complicated workflow that I can't wrap my head around. I have a simple feature branch/rebase workflow in git that has served me well for decades so I guess I don't understand why I would want to complicate things with (in this case) an "octopus merge/megamerge". Wouldn't that make it more difficult to reason about the repository/history?

I think I'm missing some major selling point of jj, to me it's just git with a different flow that might be more suitable for a rare few cases where heavy parallel work is happening, and even then git is fine if people know what they're doing, the idea of no staging areas doesn't appeal to me, mutable commits seems actively negative to me personally.

I understand if people are enjoying it great, but the amount of praise and 'this is revolutionary' comments I see makes me really feel I'm missing a beat.

Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.

And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.

When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.

I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.

The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!

Some fantastic tricks in this article. Will definitely improve my Megamerge game. Thanks!

Though, I'd be remiss not to mention that this (and any other) jj workflow would be much easier with jjui. It's the best TUI around, not just for jj

I proposed incorporating some of this article into it. https://github.com/idursun/jjui/discussions/644

I do not understand the appeal of the workflow of working on separate things in parallel, then splitting it off into branches/commits. imo, isn't it better to fully focus on one thing at a time, even if it is "simple"?

I imagine if I follow this workflow, I might accidentally split it off in a way that branch A is dependent on some code changes in branch B, and/or vice versa. Or I might accidentally split it off in a way that makes it uncompilable (or introduce a subtle bug) in one commit/branch because I accidentally forgot there was a dependency on some code that was split off somewhere else. Of course, the CI/CD pipeline/reviewers/self-testing can catch this, but this all seems to introduce a lot of extra work when I could have just been working on things one at a time.

I'm open to changing my mind, I'm sure there are lots of benefits to this approach, since it is popular. What am I missing here?

Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects.

If none exist, I think there's a great opportunity there, for anyone with the knowledge and motivation to make some absolute beginner guides. Already jj is infinitely more user-friendly, and as the tool matures, it isn't far fetched to think a new generation of programmers could go straight to jj without knowing their way around git first.

Makes me happy to see the influx of jj posts as of late. Great tool. Roughly this workflow is how I convinced a few friends to finally loosen their death grip on git and try something new.

Sometimes I have several pull requests to review and none of them have any meaningful overlap (e.g. they touch code in different places, no apparent risk of overlap). So I've started making integration branches to test all of them in one go. But then I sometimes find things to improve upon. Then I might make a few commits on top of that. And then later I have to manually move them to the correct branch. I might also remove them from the integration branch, but git-rebase(1) is likely to just drop them as already-applied.

My mind was a little blown when I read about the megamerge strategy in Steve Klabnik's tutorial.[1]

Yes, Jujutsu's approach of autorebasing changes is very nice. Now all I have to do is to try it myself.

† 1: https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...

I enjoyed this article a lot, gave me some new ideas for my Jujutsu TUI, Majjit:

https://github.com/anthrofract/majjit

Been trying to get into jj lately, but I rely a lot on VS Code's git gutter to review changes as I code. Doesn't look like jj has an equivalent in VS Code. Anyone got tool recommendations?

Great writeup! I've been using `jj parallelize` [1] a lot (and wrote about it here [2]) to fan out a sequence of commits to set up a megamerge, but your stack alias sounds super useful to create them on the fly, rather than at the very end of a work stream. Thanks for the tips!

[1] https://docs.jj-vcs.dev/latest/cli-reference/#jj-parallelize [2] https://blog.chay.dev/parallelized-commits

You are not actually working in parallel. You are making the cost of stopping one thing near zero. In git, pausing A for B costs a rebase. In jj, you edit B, the stack reflows, you keep going. That is the whole thing. Context switches get cheap so you take them.

One of the golden rules of git is: Don't rewrite public history (for example by rebasing and force-pushing already published commits). The article hints at immutable and mutable commits (https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...) but I am unsure about how fundamental this protection is. I don't want to ruin my co-worker's day by accidentally rewriting public history.

>The absorb command will do a lot of this for you by identifying which downstream mutable commit each line or hunk of your current commit belong in and automatically squashing them down for you. This feels like magic every time I use it (and not the evil black box black magic kind of magic where nothing can be understood), and it’s one of the core pieces of Jujutsu’s functionality that make the megamerge workflow so seamless.

IUUC This is already implemented for git as an extension. https://github.com/tummychow/git-absorb

I think this is such a basic thing that should be part of any DVCS implementation.

Great article, Isaac!

If anyone is JJ-curious, I also can't recommend the Discord[1] enough. The community is very helpful and welcoming.

[1]: https://discord.com/invite/dkmfj3aGQN

I reluctantly stopped using mercurial 10 or so years ago, and reading this brings a little tear to my eye. Mercurial was just about where jj seems to be now. It had revsets. It had just gotten the concept of mutable and immutable commits. It had absorb. It had bookmarks. It never had an "index". The commands had human readable options like I see in this post. It could work with git repositories. Man I miss it.

I'm hesitant to pick jj up in case it ends up losing to git like mercurial did. But it's very tempting.

I found octopus megamerge hard to collaborate - my colleagues don't use JJ so they may introduce changes that would cause conflitcts to my megamerge. When you have a conflict on a change that has more than 2 parents, the conflict resolution becomes unmanageable very quickly. No merge tool can handle more than 3-way merge, so you have to do that manually.

Eventually I settled on a tree-like megamerge that's more practical: merge 2 branches at a time and merge the merged branch with the next branch. This way I only need to handle 2-way conflicts at a time which is more manageable.

Also you have to be very careful to decide the order when you (and your colleagues) are going to land the branches, or if you expect any new features other people are working on that's going to conflict with your branches. When using megamerger workflow, most of the problems come from coordinating with other colleagues.

If this works like I think it does, it might be the missing piece I've been waiting for, for actually trying jj. Thanks!

Can this technique help with fixing a bug on master then having to merge it easily to older release-branches , without resorting to cherry-picking (and losing all history)?

"Evil" merged are only evil if your tooling skips over merge commits as "unimportant" which is a common tactic to try and prune some of the crazy trees you get when hundreds of people are making merge commits into a repo which then creates its own commits for automation reasons...

I was skeptical at first but when I dragged and dropped a bookmark in `gg` then a light went on in my head. Also the fact that jujutsu does everything in "detached mode" locally means that you can't mess up your remote git repo (unless you force push all yolo from git itself, but you're never expected to do that).

How does the megamerge handle the case where two included branches overlap in changes and a new commit is made that applies to the overlap?

I love this stuff as a hobbyist, but professionally I can't help but think this is all obsolete in the age of agent-driven development. I wish jj was around a decade ago.

this is great stuff. I've been ad hoc building a version of this workflow, and it is quite fantastic.

I'm still not as smooth at figuring out conflicts on mega-rebase.

It's interesting to see the strange workflows that come from jujutsu users, as someone who works on git workflows.

There's some counterproductive stuff in there from my perspective but at its core you're keeping up a throwaway integration branch, which is helpful practice if you'll ever care about an integration. It's annoying with git because the interface for updating your throwaway integration branch is very clunky and easy to get wrong.

Finally

I saw Jujutsu on HN a few days ago and gave it a try. I picked a bunch of it up in just a couple hours and a couple days later I've completely switched to it for all my projects, it's not even close. Git is dead to me.

I just wish Jujutsu supported git tags rather than only supporting bookmarks as branches. And I also wish that Jujutsu supported preserving commit dates during rebases.

One of my absolute favorite things about Jujutsu is how easy it is to manipulate the commit graph remotely without having to manually checkout each commit first. I've been working on some pull requests to their built-in diff editor lately trying to improve the user experience enough that most conflicts will be fixable without having to use a text editor.

Also, the lack of a special staging area means you also never have to fucking stash your changes before you can do practically anything. Your changes always have a place, you can always go somewhere else and you can always come back.

Great post. Thanks for sharing.

[dead]

[dead]