What I've learned from jj

My ideal workflow is commits are as small as possible and PRs "tell a story", meaning that they provide the context for a commit.

I will split up a PR into

- Individual steps a a refactor, especially making any moves their own commits

- I add tests *before* the feature (passing, showing the old behavior)

- The actual fix or feature commit is tiny, with the diff of the tests just demontstrating how behavior changed

This makes it really fast to review a PR because you can see the motivation while only looking at a small change. No jumping around trying to figure out how the pieces fit together.

The main reason I might split up a PR like that is if one piece is likely to generate a discussion before its merged. I then make that a separate PR and as small as possible so we can have a focused discussion.

I hate squash merges.

Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.

Here’s the most relevant (to me) difference:

- The real unit of change lives in Git

- The real unit of change lives on some forge

I want it to live in Git.

>Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer.

Respectfully, that's the dumbest thing I've ever heard.

Work on your feature until it's done, on a branch. And then when you're ready, have the branch reviewed. Then squash the branch when merging it, so it becomes 1 commit.

Commit and push often, on branches, and squash when merging. Don't review commits, review the PR.

I've had people at various jobs accidentally delete a directory, effectively losing all their progress, sometimes weeks worth of work. I've experienced laptops being stolen.

If I used your system, over the years me and various colleagues would have lost work irretrievably a few times now, potentially sinking a startup due to not hitting a deadline.

I feel your approach shows a very "Nothing bad will ever happen" attitude.

Yes, of course you should have a backup. Most of those don't run every few minutes, though. Or even every few hours.

"Just trust the backup" feels like a really overkill solution for a system that has, as a core feature, pushing to a remote server. And frankly, a way to justify not using the feature.

What's the difference between this and squash merging PRs? A commit or a PR can be large. I don't see the difference.

Is this what Gerrit does?

This encourages commit size to grow drastically.

Check out jjui - it is VASTLY better, and the dev is extremely open and responsive to feature requests.

https://github.com/idursun/jjui

Hey! I'm the author of lazyjj, let me know if you are missing any features in it!

GitHub-style PRs are the worst way of reviewing changes, except (in practice, if not in theory) for all the others :P.

When my then-employer first stated using git, I managed to convince them to set up Gerrit -- I had my own personal Gerrit instance running at home, it was great. I think it lasted about a year before the popularity factor kicked in and we switched to GitLab.

At least part of the difficulty is that approximately everyone who would need to learn how to use a new mechanism is already familiar with PRs. And folk new to the industry learn pretty quickly that it's normal and "easy". The cultural inertia is immense, and that means we're much more likely to evolve our way out of the hole (or switch to a completely different paradigm) than we are to en-mass switch to a different way of working that's still Git.

There are ways to make the PR experience more reasonable; GitHub has introduced stacked PRs which queue up. Even without that, I find disabling merge commits puts my team in a sweet spot where even if I'd prefer Gerrit, I'm not tearing my hair out and neither are the rest of my team who (mostly) don't care all that much.

It's maddening, considering their size, and that there are proven other examples out there of versioned change sets and divorcing the commit ID from the content ID.

> Code review for the age of AI

Gross.

How do they compare?

I think the biggest difference is one of philosophy: in Fossil (as I understand it) every change you make to the code is tracked, and there's no concept of rebasing or making the history prettier. If you make a commit and then realise you've left some debug logs in the code, you've got to make a new commit to delete those logs. This has the advantage that you never lose data, but the disadvantage that all of those commits end up in your long-term project history, making things like bisecting or blaming more difficult.

In JJ, however, changes are explicitly mutable, which means if you finish a commit and then realise you want to go can and change something, you've got multiple ways to squash your fix directly into the original commit. In addition to this, you also have a local history of every change you make to your project (including rewriting existing commits) so you still never lose any data locally. However, when you finish adjusting your commits and push them to someone else's machine (e.g. GitHub), they will only get the finished commits, and not the full history of how you developed them.

I know some Fossil people feel very strongly that any sort of commit rewriting should be banned and avoided at all costs, because it creates a false history - you can use Jujutsu like that, but it probably doesn't add much over Fossil at the point. But in practice, I think Jujutsu strikes the right balance between allowing you to craft the perfect patch/PR to get a clean history, and preventing you from losing any data while you do that.

It looks like it is aimed at larger projects, whereas fossil is nice for personal projects because it was designed by and for a small team.

JJ itself uses Github, where as fossil is very easy to self-host including issue tracking, wiki etc.

For me, it's not so much that jj has any specific killer feature, it's that it has a fewer number of more orthogonal primitives. This means I can do more, with less. Simpler, but also more powerful, somehow.

In some ways, this means jj has less features than git. For example, jj doesn't have an index. But that's not because you can't do what the index does for you, the index is just a commit, like any other. This means you can bring to bear your full set of tools for working on commits to the index, rather than it being its own special feature. It also means that commands don't need certain "and do this to the index" flags, making them simpler overall, while retaining the same power.

Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them.

I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR.

But as far as I know you can't do that.

Graphite.dev does this, and it works great.

With jj, I often do this and use jj split -i, which opens an interactive editor (similar to git's interactive add/rebase) which I can select parts of the change to be split into a separate change/commit. This enables me to take a large piece of work, split it into individual chunks, and open PRs for each change.

I have a tool called git-split for splitting commits: https://github.com/tomjaguarpaw/git-split/

I'm not sure you'd call it "automatic" though. Were you thinking of using an LLM to split the commits with some semantic awareness? It doesn't do that!

As others have pointed out, gitignore exists and you should try and build your configuration so that most of the time you're changing gitignored files rather than checked in ones. That said, you can do some pretty cool stuff with Jujutsu in this regard. Because changes are always automatically rebased, you can often create the change that will ultimately become your final commit, then create a new change where you edit any config you need to, then a change on top of that that's basically your staging area.

For example, I recently had a set up that looked something like this:

    @ w - the checked out change where I'm editing files
    |
    * x - local config change
    |
    * y (bookmark 1) - CI config change that sets up a temp test env
    |
    * z (bookmark 2) - Start of the changes that will eventually get reviewed and merged

If I wanted this sort of setup more long term, I'd find some other way to achieve it without relying on Jujutsu, but for ad-hoc cases like this it's absolutely great.

Agreed, and these comments fail to remember you sometimes need code changes to debug. Its nice to stage/unstage code changes, and gitignore won't help u there

some of us do `git add .`, you can't ship an unbuildable commit because you forgot something

what you should have is support for local, gitignore-able config files

I'm not sure if you meant "how" or "why". As for "how", it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'.

As for "why", I think it behaves different from what you expected in two ways. The first is that `--revision` rebased only the specified revisions without theirs descendants (there's also `--source` if you want to include the descendants). The other things it that `--after` is a short form of `--insert-after`, so it's designed for inserting commits between other commits. There's also `--before/--insert-before`. There's also `--destination` which is what you expected (perhaps `--onto` would have been a better name for it). You can pass multiple commits to all these arguments, btw (yes, that includes `--destination`, so you can create new merge commits with `jj rebase`). https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase has many examples.