[doritosfan84]

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.

[Filligree]

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

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]

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

[palata]

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

I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me that I do. It's about me, my opinion should have some value, right? :-)

> It is not. There are plenty of example on this page.

The problem is that many examples, to me, sound like it's exactly like git but the author of the example doesn't know how to do it in git. For instance, you wrote a whole paragraph about "undo", as if git did not have that feature. Isn't that exactly `git reflog`? Turns out I had a need for it 2 times in the last 10 years, and it just worked.

> Simpler mental model for local change, no git stash/add necessary.

I can deal with git stash/add without feeling like I'm thinking hard. This is a class of examples that makes me think that jj is for people who are not comfortable with git.

It feels like the people who use jj tend to somehow get stuck on detached head with git, and that's a big problem for them.

Again, I'm not saying that jj is not cool, and probably I should try it. But I see a ton of comments that really, really sound like "I can't believe people still do basic arithmetic in their head: they should get a calculator and they would see how superior it is. With a calculator, you never make those frequent and annoying mistakes like 3+5=9 again! Plus you can do 403985/13 easily!". And when I say "I usually deal with basic arithmetic that I do just fine in my head, and I don't actually frequently make mistakes like 3+5=9", I feel like I sound like an elitist.

I can't remember the last time I had to do something "hard" in git. So it sounds like jj may make something simple slightly simpler, at the cost of dealing with a new tool.

[gabrielgio]

> I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me

You are in *forum* in a post *about jj* saying there is no reason to use jj. We are just interacting as you'd expect in forum. If you don't see any reason to use anything else and don't want to hear anything about it steer away from these posts.

No one is trying to convince you personally, we are just discussing the tool. Go use git and be happy.

I sincerely won't read anything else past that line.

[palata]

> You are in forum in a post about jj saying there is no reason to use jj

I honestly am not. I am genuinely interested. Everytime there is a post about jj I'm about to try, and then I see a comment like yours, saying "with jj you just use the intuitive syntax `jj git push -r '(trunk\(?.\).x#@ | @@.^)'`, which is a lot simpler than knowing about this weird concept of stash" and it makes me think that maybe, I'll try again next time.

[arp242]

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

[bravesoul2]

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]

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]

Thanks. That would make me interested in it for a personal project where I only use jj.

[stouset]

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]

What is miso?

[jph]

Possibly means mise (https://mise.jdx.dev/) which is a tool similar to uv in the sense of managing versions.

[nchmy]

Mise and jj (and the jjui TUI) are my two favourite tools, by far

[bravesoul2]

Correct mise. Sorry!

[sunshowers]

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]

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

[sunshowers]

Cool! Don't imagine it would ever be the default, though.

[steveklabnik]

I hope not, for sure.

[nchmy]

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

[arp242]

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]

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

[frizlab]

Of course! But why even bother when everything I have to do I can do with git without any problems?

[steveklabnik]

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]

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]

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.

[sunshowers]

If you hardcode the background to a fixed color, the 4-bit palette for foreground colors is generally to be avoided -- instead, use the 8-bit (256 color) or bigger palettes.

[ghoshbishakh]

So do you suggest we should avoid setting a color in our CLI app? We would take this into consideration in our next pinggy.io CLI update.

[baq]

> 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_]

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]

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.

[frizlab]

This. Exactly this.

[dcre]

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

[idoubtit]

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.

[baq]

I find

   jj rebase -b @ -d master@origin

to be an excellent improvement over anything git provides, including rerere. It's the first patch queue for git implementation that actually worked for me, which in turn makes github PR UI somewhat bearable.

I occasionally use -r, too, but most of the time it's better to

   jj squash --from ... --into @

[wredcoll]

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]

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.

[doritosfan84]

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]

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.

[maddiemort]

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

[nchmy]

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/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow

[doritosfan84]

Ah I love that megamerge example. Thanks.