I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time.
Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can work with that. I have numerous branches in flight at any given time, and my colleagues do as well. The idea of manually keeping them pointed at the right commit is just nuts.
Maybe they've fixed that astonishing choice since then, and I'd give things another go if they did. But branches and worktrees are how I operate.
Regarding the article, I have no idea what is going on as I'm red-green color deficient.
I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new <parent_change_id>` and you have a new branch.
Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?
> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes.
I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs.
As someone who doesn't know jj and read this article, it does sound like `git rebase -i` to me. I'm sure that if I actually spent time learning jj I'd know the difference though.
The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me. So for people new to software development, they can also just ask AI to deal with git, which papers over the harder parts of its UX.
I have been walking some newer programmers through Git recently, so this topic is fresh on my mind. The commands in the blog post do not look friendlier or even different.
> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development.
I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use git absorb more you'll get it", and theoretically you might be right, but... meh, I kind of doubt it.
I spoke about this before, but jj has the Blub Paradox problem, from the pg's essay Beating the Averages (https://paulgraham.com/avg.html).
Yes, you can do most commit manipulations with git just like with jj. But, users of jj know they're "looking down the power continuum" (to reuse pg's terminology) when they look at git, whereas git users cannot fathom what's exactly the deal with jj. Unfortunately, the only way to get it is to spend a week with it, with an open mind. It's close to impossible to describe it except "it's really neat" and "wow it removes all git's friction I didn't know existed".
And, apparently, there's a pattern of having to try at least two times before it becomes intuitive!
Or let an agent deal with any git nonsense. Yes I’m already aware some smart alec will lie about the time an agent totally deleted their entire repo and branch.
This is my take on it too. And I built BetterGit (https://www.satishmaha.com/BetterGit/) before agent capabilities became widespread. A lot of things in Git and existing GUIs are just cumbersome, and my app makes it better to handle the most common tasks and makes them easier. It's really meant for newcomers to Git.
BUT! You can simply ask an agent to commit every meaningful block of work. Or just ask any agent to create a JIRA ticket and start work on that named branch. Or ask it to create work trees and create a PR. Life has gotten much easier without having to fight the command line or confusing GUI UX.
I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time.
Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can work with that. I have numerous branches in flight at any given time, and my colleagues do as well. The idea of manually keeping them pointed at the right commit is just nuts.
Maybe they've fixed that astonishing choice since then, and I'd give things another go if they did. But branches and worktrees are how I operate.
Regarding the article, I have no idea what is going on as I'm red-green color deficient.
I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new <parent_change_id>` and you have a new branch.
Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?
> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes.
I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs.
[0]: https://github.com/tummychow/git-absorb
Also `sl absorb`.
So... git rebase -i?
No, more like:
The main difference to jj is that the RED commit is created later with git.Definitely not. Switch to a previous commit, make edits, changes propagate into the future commits (including into a git repo if you wish [1])
Jj is not git and is not a git tool, it just (thankfully) uses git as a backend, so you can still carry on with the rest of the world.
[1] https://news.ycombinator.com/item?id=47765759
> Switch to a previous commit, make edits, changes propagate into the future commits
In what way is that different from using `git rebase -i` to edit a commit?
I'd recommend reading the post, it's not that long
As someone who doesn't know jj and read this article, it does sound like `git rebase -i` to me. I'm sure that if I actually spent time learning jj I'd know the difference though.
git rebase -i kinda sucks once you tried jj.
I'm not an expert in Magit by any means, but I bet there's a way to accomplish this in only a few keystrokes.
The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me. So for people new to software development, they can also just ask AI to deal with git, which papers over the harder parts of its UX.
I have been walking some newer programmers through Git recently, so this topic is fresh on my mind. The commands in the blog post do not look friendlier or even different.
> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development.
I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use git absorb more you'll get it", and theoretically you might be right, but... meh, I kind of doubt it.
So: Squash everything together then pick each component out by squash -i to an empty commit.
Seems straightforward, wouldn’t call it special
I think jj will never gain momentum because people only have a git mental model at this point, so won't be able to effectively reason about jj.
I spoke about this before, but jj has the Blub Paradox problem, from the pg's essay Beating the Averages (https://paulgraham.com/avg.html).
Yes, you can do most commit manipulations with git just like with jj. But, users of jj know they're "looking down the power continuum" (to reuse pg's terminology) when they look at git, whereas git users cannot fathom what's exactly the deal with jj. Unfortunately, the only way to get it is to spend a week with it, with an open mind. It's close to impossible to describe it except "it's really neat" and "wow it removes all git's friction I didn't know existed".
And, apparently, there's a pattern of having to try at least two times before it becomes intuitive!
Or let an agent deal with any git nonsense. Yes I’m already aware some smart alec will lie about the time an agent totally deleted their entire repo and branch.
This is my take on it too. And I built BetterGit (https://www.satishmaha.com/BetterGit/) before agent capabilities became widespread. A lot of things in Git and existing GUIs are just cumbersome, and my app makes it better to handle the most common tasks and makes them easier. It's really meant for newcomers to Git.
BUT! You can simply ask an agent to commit every meaningful block of work. Or just ask any agent to create a JIRA ticket and start work on that named branch. Or ask it to create work trees and create a PR. Life has gotten much easier without having to fight the command line or confusing GUI UX.
You can also have you agent use jj with this skill
https://github.com/danverbraganza/jujutsu-skill
JJ is a whole different way to think about source control. The fact that you don’t need to run an agent just to use it is a nice bonus.
Since adding https://github.com/raine/git-surgeon to my workflow and installing the skill, my LLM agents haven't felt the need for anything more.