6 ms·

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operation

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

arp242 1y ago
I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).
- sunshowers 1y ago
  I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.
  - steveklabnik 1y ago
    This has been the case, but it's worth noting that very recently, support for theming with the 256-color palette has landed too https://github.com/jj-vcs/jj/pull/6763 https://github.com/jj-vcs/jj/pull/6763
    - sunshowers 1y ago
      Cool! Don't imagine it would ever be the default, though.
      - steveklabnik 1y ago
        I hope not, for sure.
  - arp242 1y ago
    Some programs set the background colour and some don't. For example pamix sets the background to black, or tmux's statusline, or ngrok. It's not really possible to define one terminal scheme that always works.
    - steveklabnik 1y ago
      You can also configure jj to use whichever colors you'd like, in either the 16 or 256 color space: https://jj-vcs.github.io/jj/latest/config/#custom-colors-and-styles https://jj-vcs.github.io/jj/latest/config/#custom-colors-and...
      - frizlab 1y ago
        Of course! But why even bother when everything I have to do I can do with git without any problems?
        steveklabnik 1y ago
        I never said you should. If you like git, use git. One of the nicest things about jj is that it doesn't require others to use it.
    - sunshowers 1y ago
      I think it's reasonable to assume that all 12 colors that aren't black or white will be readable on the default terminal background. I sympathize with those for whom that isn't true, but please do find a different theme in that case.
      - arp242 1y ago
        How would that work with applications that hard-code the background to black (or some other colour, like tmux's green statusline)? If you change the colours to work on a light background then those break. You have to choose what you want to break. Once you start pulling on one thread lots of stuff start to unravel. It's really not a simple matter of "choosing a better theme". I've spent a long time looking at this, and my conclusion is that there is no safe default that will work for everyone, other than bold/reverse and 256/true colours and setting both the foreground and background.
  - nchmy 1y ago
    Jjui is by far the best TUI for jj and just released a Themes feature yesterday. It's well worth checking out. https://github.com/idursun/jjui https://github.com/idursun/jjui
- bravesoul2 1y ago
  Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it. Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.
  - sunshowers 1y ago
    Note that jj is not a frontend for git or an abstraction layer over git — rather, the git object store format is one of at least two backends to jj.
    - bravesoul2 1y ago
      Thanks. That would make me interested in it for a personal project where I only use jj.
      - stouset 1y ago
        There's really no cost to trying it out on an existing project with other people. It natively interoperates with git. Nobody needs to know you're using something different, and you can always fall back to using git commands if you need to do something you haven't learned yet.
  - what 1y ago
    What is miso?
    - jph 1y ago
      Possibly means mise (https://mise.jdx.dev/ https://mise.jdx.dev/) which is a tool similar to uv in the sense of managing versions.
      - nchmy 1y ago
- frizlab 1y ago
  This. Exactly this.
- baq 1y ago
  > By and large, it works well enough. be wary of the stockholm syndrome. I too love git, but it is a very cumbersome tool for some workflows.
  - Cthulhu_ 1y ago
    But does Jujutso solve those workflows, or does it add a layer on top that you need to figure out on top of what you already know about Git? I don't run into any issues with Git during my day to day. Some things could be a bit more ergonomic but that's because I'm too stubborn to learn or set up some aliases or look up how to do it. Following this tutorial, I can't say jujutsu feels like an improvement. More complicated log output (I use a shorthand (think "git log --oneline --graph" but with a custom output format to also show absolute and relative commit time and author)), automatic staging (that can be turned off but why should I when it's already off if I don't use jj?) while I use "git add -p" through an alias, and the rest is just push / pull / checkout / reset.
    - baq 1y ago
      jj solves one particular issue I have with git and github: truly easy (not just 'possible') rebasing of branches and editing commits which are not heads. You need to commit conflicts to solve this properly, which is something git really doesn't want you to do.
dcre 1y ago
Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html https://lottia.net/notes/0013-git-jujutsu-miniature.html
- doritosfan84 1y ago
  Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.
  - dcre 1y ago
    Yep, I think that's right. As the other reply says, this is part of what makes it hard to explain. If you told me jj makes it easy to rebase all the time, I would ask: why do I want to do that? Now I don't even think about it, I just rebase all the time.
- wredcoll 1y ago
  This article convinces me that what he wants to do is easier in jj, I just don't understand why he wants to do it. My quick summary is that in one case he's try to avoid "extra" commits and in another case he's trying to re-order some commits. In my usual work flow, both of those problems would be handled by the git-rebase-squash I do after the feature works.
  - dcre 1y ago
    See the other replies: the point is that jj makes these operations so trivial that if you have the slightest whim to do them, you can just do them.
- idoubtit 1y ago
  I think that comparison is unclear and unfair. The core is that instead of: jj rebase -r @ -B abc the recommended Git alternative is: git rebase -i abcd1234 # move the last line to the desired position This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits). I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.
Filligree 1y ago
> I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. What I find isn't that common git operations are easier in jujutsu. They're not; sometimes they're slightly harder, due to the impedance mismatch with the git backend. Rather, what git makes easier are operations that are next to impossible — or at least highly inconvenient — in git, and which therefore next to no-one does. That makes it harder to explain, because you're telling them there's this great new workflow that does stuff that... they don't think they need (they have workarounds), and the notion of which triggers their ick reflex if they're good at programming.
- palata 1y ago
  I do understand that point, but to me it sounds like "you should use jj because it's a lot better at solving problems you don't have". If there are really common use-cases where git is annoying and jj is great, it shouldn't be that hard to explain, should it? If you can say "remember how in the last few days you struggled with this? Jujutsu solves it", then I'm happy to try. If your argument starts with "imagine you are in a team that looks like X (but your team does not), with a project that looks like Y (but your project does not), and now imagine that you need to do this thing that you have never done before...", then maybe I actually don't need jj?
  - gabrielgio 1y ago
    > "you should use jj because it's a lot better at solving problems you don't have" It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve" > it shouldn't be that hard to explain, should it? It is not. There are plenty of example on this page. For me the biggest one is stacked PR, jj makes it trivial since it tracks the change sets and not commit ids (which are immutable). So you can work on any level of the stacked PR independently, once you're done run "jj git push -r '(trunk()..@ | @::)'" and it will update all the remote branches accordingly. Another feature that works great with stacked PR is that you don't need to solve conflicts right away. You will see a marker in the "jj log" and you can solve it later down the road. Also another great feature is the operation log, you can just rewind your actions. F'd up a conflict resolution? Just go "jj op undo". That goes for everything, including file changes and rebases. Want to go back the state it was 15 min ago because you didn't like what you did? Merge to the wrong place? "jj op undo" Adding to that there are hundreds paper cuts that jj fixes, like: * Simpler mental model for local change, no git stash/add necessary. * Simpler commit process, you can just work and use "jj describe" whenever where git forces you to write message before creating commit (again because commits are immutable). * Starting a work is much easier, I can just go "jj new" away without caring about detached head. Nowdays I just use branches (jj bookmarks) for git compatibility reasons. * Revsets are amazing, much more powerful and expressive than git logs, and since the UX is more consistent you can always work with set of rules that expects a revset with "-r". Ofc, you can do all of that with git, but it just works better, easier and more consistent with jj.
nchmy 1y ago
Here's a few great links that might be what you're looking for https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
- doritosfan84 1y ago
  Ah I love that megamerge example. Thanks.
maddiemort 1y ago
I think you'll probably like the next part I'm going to add to this post, then! I'm sure it'll get posted separately, but it'll also appear at the bottom of the page linked here when it's up (hopefully soon, as in the next few days).

arp242 1y ago

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

sunshowers 1y ago
I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.
- steveklabnik 1y ago
  This has been the case, but it's worth noting that very recently, support for theming with the 256-color palette has landed too https://github.com/jj-vcs/jj/pull/6763 https://github.com/jj-vcs/jj/pull/6763
  - sunshowers 1y ago
    Cool! Don't imagine it would ever be the default, though.
    - steveklabnik 1y ago
      I hope not, for sure.
- arp242 1y ago
  Some programs set the background colour and some don't. For example pamix sets the background to black, or tmux's statusline, or ngrok. It's not really possible to define one terminal scheme that always works.
  - steveklabnik 1y ago
    You can also configure jj to use whichever colors you'd like, in either the 16 or 256 color space: https://jj-vcs.github.io/jj/latest/config/#custom-colors-and-styles https://jj-vcs.github.io/jj/latest/config/#custom-colors-and...
    - frizlab 1y ago
      Of course! But why even bother when everything I have to do I can do with git without any problems?
      - steveklabnik 1y ago
        I never said you should. If you like git, use git. One of the nicest things about jj is that it doesn't require others to use it.
  - sunshowers 1y ago
    I think it's reasonable to assume that all 12 colors that aren't black or white will be readable on the default terminal background. I sympathize with those for whom that isn't true, but please do find a different theme in that case.
    - arp242 1y ago
      How would that work with applications that hard-code the background to black (or some other colour, like tmux's green statusline)? If you change the colours to work on a light background then those break. You have to choose what you want to break. Once you start pulling on one thread lots of stuff start to unravel. It's really not a simple matter of "choosing a better theme". I've spent a long time looking at this, and my conclusion is that there is no safe default that will work for everyone, other than bold/reverse and 256/true colours and setting both the foreground and background.
- nchmy 1y ago
  Jjui is by far the best TUI for jj and just released a Themes feature yesterday. It's well worth checking out. https://github.com/idursun/jjui https://github.com/idursun/jjui
bravesoul2 1y ago
Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it. Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.
- sunshowers 1y ago
  Note that jj is not a frontend for git or an abstraction layer over git — rather, the git object store format is one of at least two backends to jj.
  - bravesoul2 1y ago
    Thanks. That would make me interested in it for a personal project where I only use jj.
    - stouset 1y ago
      There's really no cost to trying it out on an existing project with other people. It natively interoperates with git. Nobody needs to know you're using something different, and you can always fall back to using git commands if you need to do something you haven't learned yet.
- what 1y ago
  What is miso?
  - jph 1y ago
    Possibly means mise (https://mise.jdx.dev/ https://mise.jdx.dev/) which is a tool similar to uv in the sense of managing versions.
    - nchmy 1y ago
frizlab 1y ago
This. Exactly this.
baq 1y ago
> By and large, it works well enough. be wary of the stockholm syndrome. I too love git, but it is a very cumbersome tool for some workflows.
- Cthulhu_ 1y ago
  But does Jujutso solve those workflows, or does it add a layer on top that you need to figure out on top of what you already know about Git? I don't run into any issues with Git during my day to day. Some things could be a bit more ergonomic but that's because I'm too stubborn to learn or set up some aliases or look up how to do it. Following this tutorial, I can't say jujutsu feels like an improvement. More complicated log output (I use a shorthand (think "git log --oneline --graph" but with a custom output format to also show absolute and relative commit time and author)), automatic staging (that can be turned off but why should I when it's already off if I don't use jj?) while I use "git add -p" through an alias, and the rest is just push / pull / checkout / reset.
  - baq 1y ago
    jj solves one particular issue I have with git and github: truly easy (not just 'possible') rebasing of branches and editing commits which are not heads. You need to commit conflicts to solve this properly, which is something git really doesn't want you to do.

dcre 1y ago

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html https://lottia.net/notes/0013-git-jujutsu-miniature.html

doritosfan84 1y ago
Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.
- dcre 1y ago
  Yep, I think that's right. As the other reply says, this is part of what makes it hard to explain. If you told me jj makes it easy to rebase all the time, I would ask: why do I want to do that? Now I don't even think about it, I just rebase all the time.
wredcoll 1y ago
This article convinces me that what he wants to do is easier in jj, I just don't understand why he wants to do it. My quick summary is that in one case he's try to avoid "extra" commits and in another case he's trying to re-order some commits. In my usual work flow, both of those problems would be handled by the git-rebase-squash I do after the feature works.
- dcre 1y ago
  See the other replies: the point is that jj makes these operations so trivial that if you have the slightest whim to do them, you can just do them.
idoubtit 1y ago
I think that comparison is unclear and unfair. The core is that instead of: jj rebase -r @ -B abc the recommended Git alternative is: git rebase -i abcd1234 # move the last line to the desired position This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits). I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.

Filligree 1y ago

> I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. What I find isn't that common git operations are easier in jujutsu. They're not; sometimes they're slightly harder, due to the impedance mismatch with the git backend. Rather, what git makes easier are operations that are next to impossible — or at least highly inconvenient — in git, and which therefore next to no-one does. That makes it harder to explain, because you're telling them there's this great new workflow that does stuff that... they don't think they need (they have workarounds), and the notion of which triggers their ick reflex if they're good at programming.

palata 1y ago
I do understand that point, but to me it sounds like "you should use jj because it's a lot better at solving problems you don't have". If there are really common use-cases where git is annoying and jj is great, it shouldn't be that hard to explain, should it? If you can say "remember how in the last few days you struggled with this? Jujutsu solves it", then I'm happy to try. If your argument starts with "imagine you are in a team that looks like X (but your team does not), with a project that looks like Y (but your project does not), and now imagine that you need to do this thing that you have never done before...", then maybe I actually don't need jj?
- gabrielgio 1y ago
  > "you should use jj because it's a lot better at solving problems you don't have" It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve" > it shouldn't be that hard to explain, should it? It is not. There are plenty of example on this page. For me the biggest one is stacked PR, jj makes it trivial since it tracks the change sets and not commit ids (which are immutable). So you can work on any level of the stacked PR independently, once you're done run "jj git push -r '(trunk()..@ | @::)'" and it will update all the remote branches accordingly. Another feature that works great with stacked PR is that you don't need to solve conflicts right away. You will see a marker in the "jj log" and you can solve it later down the road. Also another great feature is the operation log, you can just rewind your actions. F'd up a conflict resolution? Just go "jj op undo". That goes for everything, including file changes and rebases. Want to go back the state it was 15 min ago because you didn't like what you did? Merge to the wrong place? "jj op undo" Adding to that there are hundreds paper cuts that jj fixes, like: * Simpler mental model for local change, no git stash/add necessary. * Simpler commit process, you can just work and use "jj describe" whenever where git forces you to write message before creating commit (again because commits are immutable). * Starting a work is much easier, I can just go "jj new" away without caring about detached head. Nowdays I just use branches (jj bookmarks) for git compatibility reasons. * Revsets are amazing, much more powerful and expressive than git logs, and since the UX is more consistent you can always work with set of rules that expects a revset with "-r". Ofc, you can do all of that with git, but it just works better, easier and more consistent with jj.

nchmy 1y ago

Here's a few great links that might be what you're looking for https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow

doritosfan84 1y ago
Ah I love that megamerge example. Thanks.

maddiemort 1y ago

I think you'll probably like the next part I'm going to add to this post, then! I'm sure it'll get posted separately, but it'll also appear at the bottom of the page linked here when it's up (hopefully soon, as in the next few days).