10 ms·

What I've learned from jj

217 points by eproxus 1y ago

account-5 1y ago
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.
- graemep 1y ago
  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.
  - dcre 1y ago
    jj is just a CLI, analogous to git alone. It doesn’t come with any of the other stuff Fossil does. I don’t think large/small project makes any difference either.
- MrJohz 1y ago
  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.
  - matkoniecz 1y ago
    > 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. how you deal with accidental committing of text that was not supposed to be there (say, accidental pasting a private email)?
    - shakna 1y ago
      Fossil can purge certain checkins, but it isn't intuitive, and will throw away both what you want to remove, and anything that you wanted to keep. Its a bit of a manual rebuild.
2freedi 1y ago
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. `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`. 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]. It's been a seamless transition for me, and I intend to use Jujutsu for years. [1] https://github.com/Cretezy/lazyjj https://github.com/Cretezy/lazyjj [2] https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-commits https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...
- nchmy 1y ago
  Check out jjui - it is VASTLY better, and the dev is extremely open and responsive to feature requests. https://github.com/idursun/jjui https://github.com/idursun/jjui
  - ramon156 1y ago
    What makes it extremely better?
    - nchmy 1y ago
      Far more commands/shortcuts, capabilities etc... Just try the various tools out. I am not aware of anything that comes close.
- CraftThatBlock 1y ago
  Hey! I'm the author of lazyjj, let me know if you are missing any features in it!
yowlingcat 1y ago
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.
- steveklabnik 1y ago
  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.
KwanEsq 1y ago
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.
- dorian-graph 1y ago
  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.
- andrewaylett 1y ago
  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.
  - verall 1y ago
    I get to use both Gerrit (rebase-cherrypick workflow) and gitlab (PR/MR workflow) at work. I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push. I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point. So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.
abcd_f 1y ago
A thing to learn from JJ's performance is that not everyone is cut out to direct Star Wars movies.
- FridgeSeal 1y ago
  Or Star Trek.
renerick 1y ago
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
dorian-graph 1y ago
Like the author, I'd appreciate a stacked PRs approach, 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 just works.
- IshKebab 1y ago
  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.
  - xrd 1y ago
    If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr. Is that what you want?
    - aaomidi 1y ago
      That works but depending on how you merge the PR, you end up needing to do a rebase on all of your future PRs. I really wish 1PR = 1 commit with revision based diffs. Similar to gerrit.
    - IshKebab 1y ago
      Not really. I've tried that with Gitlab, but it's kind of awkward. My PR isn't to merge branch B into branch A. For instance if the project owners see the PR for B and say "yeah great! I'll merge this" and press merge, it will just merge it into branch A and then close your PR! It's a hacky workaround at best. I want proper support. I want Github to disable the merge button until the dependencies are merged. I want it to actually list the dependencies and link to them. I want the target branch to be `main`. I think if they did those 3 things it would go 90% of the way. Too much to ask though clearly.
k__ 1y ago
I often have "no changes" in my Codespaces, because I haven't committed then yet. Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.
jffhn 1y ago
Jujutsu - I like the name. I often see programming as going MMA with data, until you get what you want out of it. Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
- az09mugen 1y ago
  Agreed, I'd just like to complement vibe coding feels like spamming retarded Mr Meeseeks hoping they get get the job done. It's _probabilistic programming_
deleted 1y ago
[deleted]
cadamsdotcom 1y ago
It’s clear from multiple posts over years that jj has a better UX than plain git. Why not just merge it into git?
- wmf 1y ago
  It's too different. At best you could make it an off-by-default mode. And I'm sure there are some people who actually prefer Sapling or raw git.
- matkoniecz 1y ago
  personally, I am not interested in learning bunch of new interfaces to be - maybe - marginally more efficient and deal with more abstractions layers if anything goes wrong > It’s clear from multiple posts over years that jj has a better UX than plain git. it is clear that multiple people like it not that UX is strictly superior
cornstalks 1y ago
> 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 loathe 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. 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. 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.
- wtallis 1y ago
  Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.
  - marssaxman 1y ago
    How often do you find that command useful? In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.
    - isleyaardvark 1y ago
      Often enough that I am truly shocked to hear someone say they have never needed it.
    - turbocon 1y ago
      Honestly if you haven't ever used got bisect I'd say you're missing out on a very powerful tool. To be able to, without any knowledge of the code base, isolate down to the exact commit that introduced a big is incredibly powerful
    - 1y ago
hbay 1y ago
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. I've settled on using Interactive Git Log in VSCode.
cole_ 1y ago
Surprised no one has mentioned https://graphite.dev/ https://graphite.dev/ yet. Our team uses it for stacked PRs, and it works really well.
- esafak 1y ago
  How do they compare?
  - jmmv 1y ago
    Jujutsu is “just” a piece of software that you install, and it is free and open source. Graphite.dev is a service, and it is not free, but as a service it gives you features that Jujutsu cannot like automatically merging stacked PRs. For something as fundamental as source control in this day and age, I’d go with the former open source option (and have recently been learning Jujutsu)…
- hdjrudni 1y ago
  > Code review for the age of AI Gross.
sashank_1509 1y ago
Sounds a lot like what’s being used internally at Google
- dijit 1y ago
  The workflow is indeed similar to perforce/piper “shelves”.
- Valodim 1y ago
  It is a 20% project that became a full time thing and is used internally at Google, afaik
nonethewiser 1y ago
As entrenched as git is, I feel like its only a matter of time until it's dethroned. 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. 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.
- matkoniecz 1y ago
  > you try find the parent of a given branch what you mean by that?
- actinium226 1y ago
  I think the larger holes in git are its lack of reasonable support for large files and also its inability to keep secrets. Both relate to the same fundamental problem/feature that a git commit is a hash of its contents, including previous content (via the parent commit, who's hash is part of the input for the child commit hash).
hdjrudni 1y ago
> 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, How did t end up after u? I'd expect that to fork into (s -> t) and (s -> u -> v). Either that or maybe (s -> t -> v) and (s -> u).
- martinvonz 1y ago
  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 https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase has many examples.
  - hdjrudni 1y ago
    > it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'. That sounds like 2 operations, not 1. I think that's why I was confused. The docs do clarify that there's an extra rebase going on though, so thanks! Yes, -d sounds like what I expected.
manchmalscott 1y ago
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 :/
- nasso_dev 1y ago
  What I do is I git clone --recursive and then init a colocated repository. JJ will find the submodules and ignore anything in them, it works decently well.
sigmonsays 1y ago
i'm growing tired of these git alternatives. I feel like people should just learn to use git.
- mtndew4brkfst 1y ago
  If anything, I think the jujutsu project as it exists today is probably most attractive to people who already know Git quite well. It's hard to articulate why a given VCS design or workflow is pleasant without having some firsthand experience of nontrivial things that went wrong or at least chaotic. Among the hard work on the jj maintainers' plate is making it just as attractive and intuitive to people without that background.
- shandor 1y ago
  Why on Earth would these be in any way incompatible? I’ve been using git for 15+ years,and definitely share the sentiment that basically everyone needs to learn it well as it is just that entrenched. …but I love that people are coming up with potential alternatives that have a meaningful chance of moving the whole VCS space forward.
- jFriedensreich 1y ago
  jj seems to be the slowly evolving winner of these alternatives. It just does things on top of git that you cannot do by using git directly no matter how well you know git.
- baq 1y ago
  git is dumb. it's in the name. it's good enough, but it is not the best possible tool. neither is jj, but it's a damn fine improvement in some workflows.
- medler 1y ago
  jj is compatible with git repos while being faster to learn and easier to use. There’s basically no reason for anyone to learn git now that this exists.
aiiizzz 1y ago
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.
- mtndew4brkfst 1y ago
  There are many available paths to learning that don't leave you beholden to what was in training data from ~2021. This attitude will definitely hurt one's opportunities for personal growth and enrichment.
esafak 1y ago
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.
- CraftThatBlock 1y ago
  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.
- tome 1y ago
  I have a tool called git-split for splitting commits: https://github.com/tomjaguarpaw/git-split/ 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!
  - esafak 1y ago
    It should be possible to do that with LLM integration. Consider it a feature request :)
theusus 1y ago
I used jj for a bit. It messed up my code, put everything in staged and what not. I might try it again when it's stable.
- baq 1y ago
  It's by design. It's quite stable, too. You were probably confused by assuming it works like git, it really doesn't when you're working on a change. It kinda starts looking like git when changes are committed and pushed to master/main.
  - theusus 1y ago
    I know what I said.
n4r9 1y ago
> 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 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.
- arccy 1y ago
  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
- MrJohz 1y ago
  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 With this set up, I could make changes in an environment that included all of the config changes I needed. Then when I was happy with something and wanted to "save my work", I could run `jj squash --to z`, which would squash everything in change w into change z, rebasing everything else automatically on top of that. Then I could run `jj git push`, and this force-pushed the changes at y and z to their separate branches on GitHub. I had a pull request for the branch at z which other people could then review and where all the tests could run. Meanwhile the branch at y had updated the CI config to remove the usual tests and deploy everything to a temporary environment. So each push automatically updated my test env, and updated the pull request with the "clean" changes (i.e. without my config file fiddling). 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.
jFriedensreich 1y ago
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.)
deleted 1y ago
[deleted]

217 points by eproxus 1y ago

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.

graemep 1y ago
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.
- dcre 1y ago
  jj is just a CLI, analogous to git alone. It doesn’t come with any of the other stuff Fossil does. I don’t think large/small project makes any difference either.
MrJohz 1y ago
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.
- matkoniecz 1y ago
  > 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. how you deal with accidental committing of text that was not supposed to be there (say, accidental pasting a private email)?
  - shakna 1y ago
    Fossil can purge certain checkins, but it isn't intuitive, and will throw away both what you want to remove, and anything that you wanted to keep. Its a bit of a manual rebuild.

2freedi 1y ago

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. `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`. 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]. It's been a seamless transition for me, and I intend to use Jujutsu for years. [1] https://github.com/Cretezy/lazyjj https://github.com/Cretezy/lazyjj [2] https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-commits https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...

nchmy 1y ago
Check out jjui - it is VASTLY better, and the dev is extremely open and responsive to feature requests. https://github.com/idursun/jjui https://github.com/idursun/jjui
- ramon156 1y ago
  What makes it extremely better?
  - nchmy 1y ago
    Far more commands/shortcuts, capabilities etc... Just try the various tools out. I am not aware of anything that comes close.
CraftThatBlock 1y ago
Hey! I'm the author of lazyjj, let me know if you are missing any features in it!

yowlingcat 1y ago

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.

steveklabnik 1y ago
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.

KwanEsq 1y ago

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.

dorian-graph 1y ago
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.
andrewaylett 1y ago
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.
- verall 1y ago
  I get to use both Gerrit (rebase-cherrypick workflow) and gitlab (PR/MR workflow) at work. I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push. I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point. So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.

abcd_f 1y ago

A thing to learn from JJ's performance is that not everyone is cut out to direct Star Wars movies.

FridgeSeal 1y ago
Or Star Trek.

renerick 1y ago

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

dorian-graph 1y ago

Like the author, I'd appreciate a stacked PRs approach, 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 just works.

IshKebab 1y ago
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.
- xrd 1y ago
  If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr. Is that what you want?
  - aaomidi 1y ago
    That works but depending on how you merge the PR, you end up needing to do a rebase on all of your future PRs. I really wish 1PR = 1 commit with revision based diffs. Similar to gerrit.
  - IshKebab 1y ago
    Not really. I've tried that with Gitlab, but it's kind of awkward. My PR isn't to merge branch B into branch A. For instance if the project owners see the PR for B and say "yeah great! I'll merge this" and press merge, it will just merge it into branch A and then close your PR! It's a hacky workaround at best. I want proper support. I want Github to disable the merge button until the dependencies are merged. I want it to actually list the dependencies and link to them. I want the target branch to be `main`. I think if they did those 3 things it would go 90% of the way. Too much to ask though clearly.

k__ 1y ago

I often have "no changes" in my Codespaces, because I haven't committed then yet. Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.

jffhn 1y ago

Jujutsu - I like the name. I often see programming as going MMA with data, until you get what you want out of it. Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.

az09mugen 1y ago
Agreed, I'd just like to complement vibe coding feels like spamming retarded Mr Meeseeks hoping they get get the job done. It's _probabilistic programming_

deleted 1y ago

[deleted]

cadamsdotcom 1y ago

It’s clear from multiple posts over years that jj has a better UX than plain git. Why not just merge it into git?

wmf 1y ago
It's too different. At best you could make it an off-by-default mode. And I'm sure there are some people who actually prefer Sapling or raw git.
matkoniecz 1y ago
personally, I am not interested in learning bunch of new interfaces to be - maybe - marginally more efficient and deal with more abstractions layers if anything goes wrong > It’s clear from multiple posts over years that jj has a better UX than plain git. it is clear that multiple people like it not that UX is strictly superior

cornstalks 1y ago

> 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 loathe 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. 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. 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.

wtallis 1y ago
Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.
- marssaxman 1y ago
  How often do you find that command useful? In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.
  - isleyaardvark 1y ago
    Often enough that I am truly shocked to hear someone say they have never needed it.
  - turbocon 1y ago
    Honestly if you haven't ever used got bisect I'd say you're missing out on a very powerful tool. To be able to, without any knowledge of the code base, isolate down to the exact commit that introduced a big is incredibly powerful
  - 1y ago

hbay 1y ago

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. I've settled on using Interactive Git Log in VSCode.

cole_ 1y ago

Surprised no one has mentioned https://graphite.dev/ https://graphite.dev/ yet. Our team uses it for stacked PRs, and it works really well.

esafak 1y ago
How do they compare?
- jmmv 1y ago
  Jujutsu is “just” a piece of software that you install, and it is free and open source. Graphite.dev is a service, and it is not free, but as a service it gives you features that Jujutsu cannot like automatically merging stacked PRs. For something as fundamental as source control in this day and age, I’d go with the former open source option (and have recently been learning Jujutsu)…
hdjrudni 1y ago
> Code review for the age of AI Gross.

sashank_1509 1y ago

Sounds a lot like what’s being used internally at Google

dijit 1y ago
The workflow is indeed similar to perforce/piper “shelves”.
Valodim 1y ago
It is a 20% project that became a full time thing and is used internally at Google, afaik

nonethewiser 1y ago

As entrenched as git is, I feel like its only a matter of time until it's dethroned. 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. 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.

matkoniecz 1y ago
> you try find the parent of a given branch what you mean by that?
actinium226 1y ago
I think the larger holes in git are its lack of reasonable support for large files and also its inability to keep secrets. Both relate to the same fundamental problem/feature that a git commit is a hash of its contents, including previous content (via the parent commit, who's hash is part of the input for the child commit hash).

hdjrudni 1y ago

> 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, How did t end up after u? I'd expect that to fork into (s -> t) and (s -> u -> v). Either that or maybe (s -> t -> v) and (s -> u).

martinvonz 1y ago
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 https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase has many examples.
- hdjrudni 1y ago
  > it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'. That sounds like 2 operations, not 1. I think that's why I was confused. The docs do clarify that there's an extra rebase going on though, so thanks! Yes, -d sounds like what I expected.

manchmalscott 1y ago

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 :/

nasso_dev 1y ago
What I do is I git clone --recursive and then init a colocated repository. JJ will find the submodules and ignore anything in them, it works decently well.

sigmonsays 1y ago

i'm growing tired of these git alternatives. I feel like people should just learn to use git.

mtndew4brkfst 1y ago
If anything, I think the jujutsu project as it exists today is probably most attractive to people who already know Git quite well. It's hard to articulate why a given VCS design or workflow is pleasant without having some firsthand experience of nontrivial things that went wrong or at least chaotic. Among the hard work on the jj maintainers' plate is making it just as attractive and intuitive to people without that background.
shandor 1y ago
Why on Earth would these be in any way incompatible? I’ve been using git for 15+ years,and definitely share the sentiment that basically everyone needs to learn it well as it is just that entrenched. …but I love that people are coming up with potential alternatives that have a meaningful chance of moving the whole VCS space forward.
jFriedensreich 1y ago
jj seems to be the slowly evolving winner of these alternatives. It just does things on top of git that you cannot do by using git directly no matter how well you know git.
baq 1y ago
git is dumb. it's in the name. it's good enough, but it is not the best possible tool. neither is jj, but it's a damn fine improvement in some workflows.
medler 1y ago
jj is compatible with git repos while being faster to learn and easier to use. There’s basically no reason for anyone to learn git now that this exists.

aiiizzz 1y ago

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.

mtndew4brkfst 1y ago
There are many available paths to learning that don't leave you beholden to what was in training data from ~2021. This attitude will definitely hurt one's opportunities for personal growth and enrichment.

esafak 1y ago

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.

CraftThatBlock 1y ago
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.
tome 1y ago
I have a tool called git-split for splitting commits: https://github.com/tomjaguarpaw/git-split/ 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!
- esafak 1y ago
  It should be possible to do that with LLM integration. Consider it a feature request :)

theusus 1y ago

I used jj for a bit. It messed up my code, put everything in staged and what not. I might try it again when it's stable.

baq 1y ago
It's by design. It's quite stable, too. You were probably confused by assuming it works like git, it really doesn't when you're working on a change. It kinda starts looking like git when changes are committed and pushed to master/main.
- theusus 1y ago
  I know what I said.

n4r9 1y ago

> 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 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.

arccy 1y ago
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
MrJohz 1y ago
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 With this set up, I could make changes in an environment that included all of the config changes I needed. Then when I was happy with something and wanted to "save my work", I could run `jj squash --to z`, which would squash everything in change w into change z, rebasing everything else automatically on top of that. Then I could run `jj git push`, and this force-pushed the changes at y and z to their separate branches on GitHub. I had a pull request for the branch at z which other people could then review and where all the tests could run. Meanwhile the branch at y had updated the CI config to remove the usual tests and deploy everything to a temporary environment. So each push automatically updated my test env, and updated the pull request with the "clean" changes (i.e. without my config file fiddling). 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.

jFriedensreich 1y ago

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.)

deleted 1y ago

[deleted]