IME, the benefit is ease of branching paths. For example, if I'm working on a feature I can do something like this:
- Put tests in one commit
- Tell Claude to come up with several approaches where I'm not exactly sure what the best might be
- Put approach 1 into a commit, 2 into a separate one, etc. These approach commits all live side by side instead of stacked on top of each other.
- At any point I can create a new commit that is the combination of approach 1 along with the tests and iterate from there
- When doing that, I can absorb any changes made into the appropriate commit.
Possibilities kinda open up from there. Maybe intead of fully separate approaches, you just want to break the change into parallel pieces (e.g. you're not sure all of your changes will be needed as requirements change). Then I can create a "super" commit that's the combination of all the other commits even though they're not stacked. That means I can conditionally choose which commits I want to include into my "super" commit too.
I don't see the correlation. Jujutsu has workspaces as the match to git's worktrees too because their worktrees are a different thing from what I'm talking about. Switching worktrees and making commits is way more work than just making commits.
Lack of staging in jj is a hard pass from me. I usually have a dozen different things I’m working on, and I commit piecemeal whenever one gets across the finish line. How do you do this in jj?
A very depressing fumble. I was very high on Arc and to see what they've done has completely turned me off the company. Hopefully their telemetry was really showing them the right things but from the Arc subreddit and other commentary there seems to be a lot of unhappy people.
I don’t think simplified model is even the best selling point, but it’s definitely up there. IMO one of the killer features that you absolutely cannot get in git is universal undo. For example, rebases can always be a little tedious and tricky no matter how experienced you are. Not only does jj make that whole process easier and safer to work through, but if you do still manage to get to a state where you just want to go back it’s literally just an undo away.
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.
> 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.
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?
> "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.
> 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.
> 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.
> 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.
If you are interest in learning you should take people words on good faith, my comment on "jj git push -r '(trunk()..@ | @::)'" is complex operation to update many stacked PRs not compared to local git index operations. Also in my comment I mentioned revsets and the "-r". It is a language to query logs which you should've check if you genuinely wanted to learn about it, which you don't.
Just look at your answer, you literately ignored everything I mentioned and took what I said out of context just to bash on jj for some reason.
Actually, to be blunt (you're already offended anyway): what I'm saying is that I find (personal opinion) that many evangelists here (you included) don't sell jj really well. If so many people are actual fans of jj, there must be something there. I'm just struggling to find it between the "you're probably too dumb to understand a stash so you should use jj" and the "let me explain to you this great concept that jj has which allows you to undo changes in a way that sounds like git cannot do exactly that".
So no, I'm not criticising jj :-). And I'm not convinced I need it.
> 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? :-)
I have no problem whatsoever if you don't like jj or use git or whatever else you like.
Let's paddle back:
- you are in post about jj
- you comment why you don't like jj
- I comment why I like jj
- you post that.
Like, what is your intention here? If you don't have good faith into trying to understand the tooling, how would it fit your workflow and deflects everything with "I know git, git works, don't tell me to use something else" what is your goal here?
My problem is not your opinion on the tool, is how you approach the debate.
I have been asking a few questions, and I have received many answers quickly. Which is usually great, but between the "those who don't use jj haven't seen the light and must be in a cult" and the "jj is better because git is impossible to use everyday", it's honestly been harder than anticipated :-).
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).
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.
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.
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
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.
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.
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.
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.
If I understand correctly, you're in the situation where you've chosen your 4-bit colors so that they render properly on an application which (incorrectly) uses an 8-bit background color but a 4-bit foreground color, and also that the colors don't render well on the default background that's part of the same 4-bit palette.
I think you'd be a great candidate for jj's ability to customize colors.
I don't choose anything; I just use the xterm defaults. Some colours inherently conflict. Blue on white is fine. Yellow on black is fine. Yellow on white is not. White on white is even worse. There are many combinations that don't really work brilliantly. Some applications set background colours, some don't. pamix, ngrok, and npm are examples of applications that hard-code background colours. Configuring the terminal to use text colours that work well with both the default white and hard-coded black (for some applications) is hard.
That I need to spend a bunch of time setting all of this up (among other things) is exactly how this thread started.
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.
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.
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.
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
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.
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.
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.
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).
every one of your "more generous" assumptions is the opposite of what should be their process. It's the equivalent of "vacuum up as much data as possible and then decide what to do with it". Not acceptable.
It's "vacuuming" that data in the sense of giving API access to a tool that runs on your local computer, that seems acceptable enough for me in the early stages of developing a tool.
The other privacy complains I have regarding them harvesting usernames and email addresses... not so much.
Because it's not "a kanban board"? It's a coding agent orchestrator that's made in the shape of a Kanban board.
You might be right that this app asks for excessively broad privileges, but your case would be much stronger if it wasn't backed by an absurdly disingenuous argument.
How do you separate the good from the bad? What do you do when Microsoft changes the good things into bad things?
My take is that Microsoft consistently makes bad things and makes "good" things into "bad" things; so, I don't have much expectation or faith that anything that I currently think is "good" will stay that way.
Services are bad - that is what the first part of the story is about.
However I do not think it is different for any online service. Any American company would have to cut off services to an individual (or organisation) subject to sanctions (the main example given). The same might apply to other countries for various reasons. There are various reasons a service might fail, or cut off a particular customer (lots of reasons, lots of examples in previous HN discussion).
What has changed is that the typical MS customer is a lot more dependent on MS services - MS 365, Python in Excel ONLY works in the cloud, people used hosted email instead of their own Exchange installation...... That means MS cutting off a customer would mean all their IT would cease working. They can just shut down any organisation with that level of dependency if they are ordered to, or decide to, do so.
I consider C# / .NET to be one of the best options for application development.
Many would consider both VSCode and Visual Code pretty good. There might be better alternatives, but generally I'd say they are more good then bad. Github is also a good product. Maybe not exactly a develop tool, but Power BI is also fairly good.
Borderline developer / enterprise solution: SQLServer is great to work with. Maybe not the best relational database server, but it's every bit as capable as MariaDB and I'd prefer it over Oracle.
Before Microsoft bought it you could still search it / codesbases without making an account. Alone for that additional pain I would argue they instantly made it worse.
Wrong about "inconsistent", the ribbon follows predictable patterns. Home tab always has basic formatting, Insert always has objects/media, etc. What changed is intelligent positioning based on context.
Office 95's menus were consistent in the worst way - consistently buried everything under nested submenus. Finding mail merge meant File→Tools→Mail Merge→Options→Setup. Now it's Mailings tab, right there.
It is a tool for people who write words. That is its prime purpose.
People write words for people to read the words. That is the prime purpose.
It is a tool for readers and writers.
I am both.
I can read a menu, and scan through submenus, about 10-20x faster than I can page through buttons on a tabbed bar. The replacement is dramatically inferior in legibility and so in efficiency.
That is 1 way it is worse.
A menu bar takes a single line of text. It works perfectly in a text-only display. A ribbon bar takes many lines of small intricate graphics. It is dramatically and measurably and demonstrably inferior in its use of screen space, its use of pixels, its adaptability to other displays, its functionality for those with restricted vision or restricted computer display abilities.
This is a 2nd way it is worse.
It is not re-orientable; I can't move it to one side to use a widescreen more efficiently. Because of its poor and fixed layout I can see less of my document, meaning it hinders the primary purpose of the tool.
This is a 3rd way it is worse.
It does not interoperate with other UI paradigms. Right now I am typing on an old Mac with macOS. Word is the only Office app on it. The oldest 64-bit version of Word I can find. It has to duplicate the entire UI both in the Mac's mandatory global menu bar and in the clumsy bolted-on Windows-centric ribbon. This demonstrates the inefficiency and poor design.
This is a 4th way it's worse, although for me, it means I can ignore the ribbon and use the menus.
I read fast. I cannot squint at tiny icons and try to guess their functions quickly. It's slow. The ribbon defeats muscle memory and defeats fast reading.
This is a 5th way it's worse.
The ribbon is context-sensitive. I can't just remember what is where under where relative to the first menu, because it changes depending on where the cursor is, what is selected, what tab I left it on last time. In a menu tree, if it's left open, I tap ESC once and I am at a known place and can start over. Not with the ribbon.
This is a 6th way it's worse.
I speedread and I have good colour vision. Some people can't see colours. Some can't see fine details. Some can't see at all. A screenreader can just read all of a menu, but it can't describe icons and it can't say "then there's a vertical line and in the next section, it starts..."
The ribbon fails at accessibility.
This is a 7th way it's worse.
Menus can be accessed and manipulated in a consistent way with keyboard controls. Up/down/left/right/enter. 5 keys and you have total control. You can use this with a mouth control if you have no use of any limbs. This is good for people with motor disabilities but it is also good for keyboard-centric users with no disabilities. This is good design: it's adaptable and it's flexible and it fits different needs. But also, you can use letters to leap faster through the menu bar, so power users and touch-typists can navigate faster. All blind people who can type are touch typists; they have no other option. So this feature that aids accessibility also aids power users.
None of this applies to the state-sensitive context-sensitive ribbon. That is an 8th way it's worse.
You are wrong, and what's more, you are wrong on multiple levels, some of which I have itemised. I could get to 10, I suspect, but I have a job to do and this is not it.
Stop defending bad design. Learn to look deeper at good design that lasted decades and learn to ask why things you don't like so much survive and are widespread and have not been replaced by novelties you like.
- Put tests in one commit - Tell Claude to come up with several approaches where I'm not exactly sure what the best might be - Put approach 1 into a commit, 2 into a separate one, etc. These approach commits all live side by side instead of stacked on top of each other. - At any point I can create a new commit that is the combination of approach 1 along with the tests and iterate from there - When doing that, I can absorb any changes made into the appropriate commit.
Possibilities kinda open up from there. Maybe intead of fully separate approaches, you just want to break the change into parallel pieces (e.g. you're not sure all of your changes will be needed as requirements change). Then I can create a "super" commit that's the combination of all the other commits even though they're not stacked. That means I can conditionally choose which commits I want to include into my "super" commit too.
reply