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

[arp242]

I don't control these applications.

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