Hacker Remix

Steve's Jujutsu Tutorial

156 points by drudru 5 days ago | 113 comments

videlov 4 days ago

Martin (the jj creator) recently gave a talk at the Git Merge 2024 conference: https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G

klauserc 4 days ago

Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration.

The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners).

The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")

atoav 4 hours ago

To me at least it makes so much more sense to be like:

1. I am going to work on $X

2. autocommit

3. My work on $X is done

rather than

1. I make changes

2. I am done making changes

3. Now I have to describe what I changed and how

Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?

steveklabnik 4 days ago

Full agreement on both “it feels weird” -> “how do people ever tolerate the old way” as well as the auto commit behavior being one of those things. In fact I probably over-index on that specifically when talking about jj. I thought I’d hate this because I love git’s index. Turns out that by getting rid of the index, jj has a better index than git does, but that sounds insane at first!

stouset 3 days ago

Same about the index! I initially skipped over jj thinking the lack of an index was a huge step backwards but commit-splitting is a massive improvement.

I do wish there was a better front end for it though.

stouset 3 days ago

100% agreement on that transition. I feel like I had to unlearn a lot of git’s subtly-broken model and now things feel so much simpler and easier.

One of those for me was branch names that don’t automatically “follow” new commits. At first it felt weird but it unlocks the ability to do consecutive work as one linear set of changes, even when those changes need to be merged in discrete chunks. The git approach for this (stacking branches) is so painful, particularly when you need to edit an earlier change or add a new commit between earlier ones. This went from being so frustratingly difficult I wouldn’t even consider it to being utterly trivial.

Also rebase conflicts. Not being unceremoniously dropped into a half-broken “fix this NOW state” with no ability to inspect and poke at other commits in the chain and not being able to fix things incrementally in any order is something I couldn’t have imagined. And like you said now it’s insane to me that people continue to put up with it.

conaclos 4 days ago

> The auto committing behavior is a bit weird at first

I am a bit skeptical about this, because this requires a jj daemon?

aseipp 4 days ago

It's a bit of a magic trick. A "snapshot" is taken any time a command is run, and it happens implicitly before any actual algorithms or code for a given command is run (massively simplifying the internal design), so for all intents and purposes it's "automatic" from the user interface e.g. even checking repo status or otherwise small operations will cause a snapshot.

But you can integrate with https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.

stouset 3 days ago

What’s also amazing is this means you’re no longer completely on your own when fixing things up.

I can’t tell you how many times I got midway through a git rebase, realize I’d fucked up earlier, and had to abort and redo everything from scratch. With jj not only is this not a problem (thanks to conflict markers being first class citizens) but also any intermediate changes are being snapshotted without me having to do anything. So I can always go back to an earlier change if need be.

The first time I had to do this I’d royally fucked up a complicated commit reordering sequence while screen sharing during a meeting. I’d never needed to use the op log before and had no idea how to use it. It took maybe a minute or two to fix things completely.

abhinavk 4 days ago

No from what I see. It does that whenever you run any jj command.

I haven't checked the source.

sheremetyev 4 days ago

by default snapshotting happens on each jj command

additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman

swiftcoder 4 days ago

> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked.

I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

steveklabnik 4 days ago

For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching…

With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in response to review comments” development style is still very rebase centric, but not stacked.

You also have to remember (though there’s no reason you should know this) that GitHub came out of the community I was heavily involved in at the time of its birth. I’ve been using GitHub for longer than most people, and so the PR-style workflow has been the air I’ve breathed for so long, it can be hard to understand other things at first. I had used subversion before git, but didn’t really understand much about it.

Anyway, that’s just a roundabout way of saying that I think this space is super interesting because these tools are so flexible that they can be used in so many different ways, and it’s easy to assume that “how you use git” is some sort of shared experience when that’s not really true.

3np 3 days ago

What I find confusing with people raving about it as something different is the considering the following scenario:

    refactor/a  # should be merged as independent PR
    feature/a-b # depends on a; should be merged independently, after
    fix/c       # independent

Then I will probably have some local `dev` branch checked out with a combination of all of the above and maybe some.

How else than "stacked diffs" would you submit all of this for review concurrently while still working on all of them? It sounds like a new word for what we were always expected to do? What's an alternative which doesn't rely on compromising merge-strategy?

At this point I'm suspecting "stacked diffs" is just a crotch for people still barely coping with DVCS but I could be missing something.

viraptor 3 days ago

GH did not really support automated base change (after merging) not that long ago, so doing this as stacked diffs/prs there was quite annoying. I guess that's why people tried to avoid it for a long time? I know I did some weird PRs in the past just to keep them independent. It could still be improved today (why is main the base when the branch contains an existing PR? adjust it automatically, please!), but it's not a big issue anymore.

stouset 3 days ago

Also this workflow is excruciatingly painful if you need to make a change or add a commit to an earlier part of the “stack”. Now you have to manually rebase everything after it one by one by one.

ykonstant 3 days ago

A crutch, I think. Or a crotch; I don't judge.

swiftcoder 4 days ago

Yeah, and I think it's also worth noting that by far the largest set of folks advocating for stacked diffs are not actually using git.

Meta runs a custom mercurial-compatible monorepo that was scaled up to handle thousands of commits per hour, and they have a culture of constant codebase-wide refactoring commits (i.e. the ongoing live migration of PHP -> Hack) - that rate of change causes problems that most GitHub projects have no reason to solve.

Kinrany 4 days ago

The holy grail of a stacked diff workflow would be making multiple Github PRs each made against the previous branch instead of trunk, and then updating the branch that's closest to trunk and rebasing all of the children PRs without having to force push into any of them.

Git and Github do not support this workflow directly, and this creates space for all the other tools.

Jujutsu comes close to supporting this workflow directly, without having to provide any specialized utilities that mention "stacked diffs" at all.

https://github.com/spacedentist/spr (not to be confused with ejoffe/spr) is a utility that maps a local change to a remote branch, updating the branch (without force pushes) when the local change is updated. (Changes work the same as they do in JJ, but the implementation is different.) And this works even when you have a stack of changes and update one in the middle of the stack.

steveklabnik 4 days ago

The https://github.com/sunshowers/spr fork supports jj :)

Kinrany 3 days ago

Beautiful, thank you!

arccy 4 days ago

because it's a name that describes the technical implementation, not the end user experience

swiftcoder 4 days ago

Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.

steveklabnik 4 days ago

This is a major issue for sure. Like a big enough one that if I was still doing major open source work, I’d be working on that.

phildenhoff 4 days ago

Steve, I see you’re in this thread. I was using jj for a while before reading your tutorial and yet still found it quite insightful and helpful. Thanks for your contribution!

steveklabnik 4 days ago

You’re welcome!