> <i>The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant.</i><p>I <i>loathe</i> GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer.<p>And you know what? I love it. Yes, there's some overhead. But I can understand each commit in its entirety. I and my coworkers have caught numerous issues in code with these single-purpose commits of digestible size.<p>Compare this to GitHub PRs, which tend to be beastly things that are poorly structured (not to mention GitHub's UI only adding to the review problems...) and multipurpose. Reviewing these big PRs with care is just so much harder. People don't care about the commit message, so looking at the git log it's just a mess that's hard to navigate.
I began using Jujutsu as my VCS about 2 months ago. Considering most of my work is on solo projects, I love the extra flexibility and speed of being able to safely fixup recent commits. I also love not having to wrangle the index, stashes, and merges.<p>`lazyjj` [1] makes it easier to navigate around the change log (aka commit history) with single keypresses. The only workflow it's currently missing for me is `split`.<p>For the times when I have had to push to a shared git repo, I used the same technique mentioned in the article to prevent making changes to other developer's commits [2].<p>It's been a seamless transition for me, and I intend to use Jujutsu for years.<p>[1] <a href="https://github.com/Cretezy/lazyjj">https://github.com/Cretezy/lazyjj</a>
[2] <a href="https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-commits" rel="nofollow">https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...</a>
Huh, reading the penultimate "“Units of change” and collaboration" section reinforces the feeling that Github PRs really are a poor way to do code submission/review, and have been holding back a lot of the industry from better ways of working for a long time.
JJ just surpassed a milestone for me personally where there were no hick-ups for more than 6 months and it feels genuinely superior to git and also to sapling for performance, stability and UX. If you ever considered switching i think it might be now. Colocated mode does not feel like a second class citizen and works really well too so there is always the option to use a sophisticated git client like fork for certain tasks. VisualJJ is also a great albeit not open source vscode extensio n that is slowly catching up to ISL. (If you are used to ISL and think visualJJ looks empty and lacks features: most things are hidden in the context menu which takes some getting used to.)
Surprised no one has mentioned <a href="https://graphite.dev/" rel="nofollow">https://graphite.dev/</a> yet. Our team uses it for stacked PRs, and it works really well.
This article covers my own experience with JJ very accurately. I'll even go as far as to say that if had to write my own article about jj, I'd use exactly the same talking points and examples. Great writeup
I would really love a comparison between JJ and fossil. I use fossil for personal projects instead of git. So I'd like to know if I should consider JJ.
Nice writeup -- had been wondering about how it compares to Git (and any killer features) from the perspective of someone who has used it for a while. Conflict markers seems like the biggest one to me -- rebase workflows between superficially divergent branches has always had sharp edges in Git. It's never impossible, but it's enough of a pain that I have wondered if there's a better way.
Like the author, I'd appreciate a stacked PRs <i>approach</i>, integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that <i>just works</i>.
When I'm developing I inevitably fix one thing after another as I pass through the code. What I'd like is a tool to take such PRs and automatically split it up into loosely coupled, cohesive chunks.
> You don’t need to explicitly tell jj about what you’ve done in your working copy, it’s already tracked. This removes the need for an “index” or staging area<p>Does this mean that you have to proactively remember and undo any config file changes you made e.g. while fixing an issue in a test environment? Sounds a little risky.
> If I had s -> t -> u -> v and wanted to reorder them, it’s as easy as jj rebase --revision u --after s, and I’d end up with s -> u -> t -> v,<p>How did t end up after u?<p>I'd expect that to fork into (s -> t) and (s -> u -> v). Either that or maybe (s -> t -> v) and (s -> u).
I've tried out jj a little bit personally, but without exaggeration I am using git submodules in every single "real" project I'm actually working on, so lacking support for submodules is a complete non-starter for me :/
As entrenched as git is, I feel like its only a matter of time until it's dethroned.<p>The basic workflow is fine. And there are some very powerful features. But then you try find the parent of a given branch and you're left wondering how the f#!@ thats so hard.<p>It's definitely nit picking. It's probably 85-90% of what you want it to be. But there is definitely enough room for improvement to warrent moving beyond it. I think the workflows and integratoins (github, gitlab, etc.) make it stickier as well. I just dont think we should assume everyone is just going to use git for the next 20+ years.
I often have "no changes" in my Codespaces, because I haven't committed then yet.<p>Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.
Jujutsu - I like the name.<p>I often see programming as going MMA with data, until you get what you want out of it.<p>Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
Skimmed the article so I admittedly can't speak to much to the content of it, but just wanted to give my 2c on working on individual things after spending a lot of time working with a stack-based VCS in mercurial/sapling -- jj felt pretty hard to get used to and after a couple of weeks I gave it up. I think it needs a competitive visualization tool to Interactive Smartlog.<p>I've settled on using Interactive Git Log in VSCode.
I've been using jj, but am considering going back to plain git now because all the latest llm tools know git and not jj. I don't recommend spending time on it now.