Rendered at 02:59:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
y1n0 5 hours ago [-]
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.
jolux 5 hours ago [-]
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?
y1n0 2 hours ago [-]
I think I said named branches, but that is definitely what I mean. I find it strange that people want to work on anonymous branches, but to each their own. I don't so that has no appeal to me.
I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
jolux 2 hours ago [-]
> I think I said named branches, but that is definitely what I mean
I think I misread you, because you were talking about git vs svn in a way that made it sound like jj was a step backward from git as regards branching, and I got confused.
> I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Right, but you can still name your branches with bookmarks, you’re just not required to. Personally, I tend to use commit descriptions more than bookmarks to keep track of what I’m working on, but this is a personal choice.
> Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
It’s just nicer as a local workflow, to me at least? I can create throwaway branches without having to come up with a name for them. I end up creating many, many more branches than I did in git as a result, which helps me keep my work better organized and my changes more focused when I submit them for others to review (which at least on GitHub, requires a bookmark of course). This is ultimately psychological because obviously I could just make up a name for the git branch, right? But it makes a big difference for me!
justinpombrio 2 hours ago [-]
> it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
em-bee 12 minutes ago [-]
that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them.
so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
nine_k 4 hours ago [-]
Imagine that you use jj, while everyone else who works on the repo along with you uses regular git.
Is it easy?
jolux 4 hours ago [-]
Yes, that describes me at both jobs I’ve had since learning jj. Hence why I asked for specifics: I’m genuinely curious what other people struggle with, partially because I’d like to help them if I can, and partially because it gives me a better understanding of common pitfalls which helps when teaching other people.
Macha 1 hours ago [-]
The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires.
Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.
stouset 4 hours ago [-]
Yes, that is the case for almost every repo I’ve ever used jj for. It is a complete non-issue. There is virtually zero friction.
rtpg 3 hours ago [-]
yeah nobody "has to know", especially if everyone else is also rebasing etc constantly.
tiltowait 3 hours ago [-]
I do this all the time at my job, without issue. I think it's honestly easier than using plain git.
jgtrosh 4 hours ago [-]
I believe this is the most common scenario, yes. If you're used to actively pushing and pulling from the same branche as your colleagues, you need to learn how to manipulate diverging changes and conflicting bookmarks, but other than that all the jj magic is limited to your local activity.
LoganDark 4 hours ago [-]
I use jj all the time for pull requests, in fact I don't use regular git at all anymore, and it's perfectly easy. Not only can I easily keep all my pull requests properly synced to their base branches, but I can easily and very quickly address review comments, keeping the commit stack clean without having to manually squash or amend or anything of that sort. Honestly it's a lot easier and more efficient than git for me because of how much naturally follows rather than requiring explicit imperative fixups.
kaladin-jasnah 58 minutes ago [-]
I like jujutsu simply because (despite my annoyances, which might be because I started using it 2 weeks ago) it's still faster than git.
I dislike this as well. I find it easier to keep track of branches with bookmarks, but my workflow still makes things cumbersome. I am usually working with the "megamerge" branches, and I usually want to add commits to my current branch instead of squashing my edits. However, adding commits means I have to add my commit, move my bookmark up to the branch tip (jj tug?), and then rebase the megamerge branch, versus doing nothing for squashing. I also find that when I mess up, I don't really love using `jj op log` to fix it. I want to not be in an environment where it's this easy to destroy history (I feel like git was on the other end of it).
stouset 4 hours ago [-]
I’ll be honest, as a long-time jj user, I actually haven’t the foggiest what you’re talking about with branches being laborious to keep up to date. Can you elaborate?
y1n0 2 hours ago [-]
I make a commit and the branch doesn't follow it. Bookmark, whatever. That is never a behavior I would want. What purpose does it serve?
paradox460 1 hours ago [-]
They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch
cpeterso 35 minutes ago [-]
Having to list all the bookmarks you would list to auto-advance in your jj config.toml is a hassle and easy to forget.
em-bee 6 minutes ago [-]
ideally this should be done automatically when you create the bookmark, maybe with a commandline option: jj bookmark create -a/--auto-advance ...
kccqzy 2 hours ago [-]
You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions.
That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and deletes remote git branches (`jj git push -c` for creation, plain `jj git push` for updates, `jj git push --deleted` for deletions). I do not ever have to think about branch names and it is great!
dzaima 1 hours ago [-]
But you probably haven't spent time writing commit messages before a branch is finished. Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change; replacing a chore with a much bigger chore.
Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent branches, than scanning through 50 commits, when trying to remember where some work last was, and which is the proper end-point instead of some failed attempt or unrelated change.
Unnamed branches are quite neat - I certainly have a lot more of such than named ones in jj - but as such named branches are, if anything, more important as a result, for separating sequences of changes striving towards a goal, from the sea of smaller experiments.
kccqzy 1 hours ago [-]
> But you probably haven't spent time writing commit messages before a branch is finished.
Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do.
> Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change.
Rewriting it is not wasted time. It is an opportunity to look at what I have written in the plan and check whether I have really executed them, and then rephrase things to be more easily understandable.
> Restricted and summarized is good - easier to find/remember, less fluff in a list.
The first line of a commit message is already a summary of the work done. And you can use actual English instead of trying to awkwardly avoid spaces in your words.
dzaima 19 minutes ago [-]
> It is like writing out a plan for what I want to do.
I usually don't have a plan for the end; certainly not what any specific commit would be; sure, I could make one (and either make my future self have to do extra work to figure out what commits with lies in their descriptions actually do, or continuously update the commit message marking what actually exists), but as I said that's basically a waste of time. (if you like comparing with past thoughts, sure, but that's definitely not a necessity for a workflow to be reasonable)
"is/isn't an ancestor of the bookmark" is also just a pretty damn good short-hand for denoting a separation between what's been considered the best attempt at the goal, vs things with known problems or just unrelated to the task.
At the core, this if all of course just a question of workflow; if you go into a thing with a plan, meaningful outlook of a non-vague destination, and without expecting continuous switching back&forth between a dozen other things over the time span the branch is alive, caring less about branches or branch names can perhaps work.
> The first line of a commit message is already a summary of the work done.
But you can't (sanely) use it to reference the branch in a revset, can't find it anywhere other than the full log (that's interleaved and mixed with a bunch of other things that you won't ever need to search for), and actual English just gets in the way for finding it, remembering it, and identifying it in a list.
This alone means that, even if I found interest in massively-ahead-of-time-describing commits, having a sane branch reference is still simply just necessary.
y1n0 2 hours ago [-]
Yeah, I don't get it. I'm sure it's because we work differently and that's fine.
But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that everyone that likes JJ isn't really doing collaboration.
Macha 1 hours ago [-]
When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.
kccqzy 1 hours ago [-]
I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects.
> having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters
In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.
cpeterso 31 minutes ago [-]
I name my branches for the overall task. The description of the branch’s head commit in jj status doesn’t tell the whole story.
rmwaite 3 hours ago [-]
I remember being the big innovation over svn being merging. There were others things, obviously, but the distributed model + easy merges is what I remember.
kccqzy 1 hours ago [-]
If the big innovation over svn is merging for git, then the big innovation here is conflicts. I hate the fact that git requires you to stop everything and fix the merge conflict when you merge. I especially hate the fact that when rebasing in git sometimes it requires you to solve conflicts one by one. The big innovation here is jj does not require you to resolve merge conflicts in a timely manner; it simply records the fact that there are conflicts in the file and you go about your ways. You don't ever have to abort like `git rebase --abort` or `git merge --abort`.
y1n0 2 hours ago [-]
Yes, that's true, merging. Which is what made branching a reasonable thing to do.
LoganDark 4 hours ago [-]
I don't try to reimplement the git workflow on top of Jujutsu. I like it because I can let go of a bunch of annoying noise that I needed in Git. I like it because rebases don't have to be synchronous and modal. I like it because I can easily edit history, rearrange the commit graph, change commit descriptions, duplicate, and so much more, and even remotely (without having to checkout first). There's so much to love that I never could've even dreamed of under Git.
That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed.
But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.
RobotCaleb 2 hours ago [-]
I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line
jwiz 36 seconds ago [-]
The delay is on HN side, when people reply too quickly.
throawayonthe 3 hours ago [-]
tbh i never actually learned git, but peope working on the same repos with git seem to be ahme ones struggling with named branches... i just do jj rebase and it just works idk
NamlchakKhandro 1 hours ago [-]
Feel the same way about JJ.
It feels like Apple vs Linux. Apple being different ... just because (it gives them an artificial moat)
winterqt 5 hours ago [-]
> `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.
Yeah it’s smarter than that, but as a daily user of git absorb it still gets things wrong fairly often though—like a couple times a week often for me. Plus the changes it can’t absorb automatically (e.g. a lone doc change it can’t find peers for).
ikesau 4 hours ago [-]
Ah yeah, you're right, that's a misrepresentation on my part - it's based on lines, not the file:
> [absorb] splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.
I use absorb fairly often, fwiw. It's great for when I want to make a patch to a commit that will easily absorb into its right place. And I also, sometimes, prefer the more intentional approach where I decide exactly where each hunk will go.
jolux 5 hours ago [-]
Also `sl absorb`.
stouset 4 hours ago [-]
This seems like a lot more effort than the (to me) more natural jj workflow of maintaining the idealized series of commits plus a working commit on top. As you make tweaks and fixes you just squash the relevant parts into the already-clean history.
Basically, if you don’t get into that sort of situation with commits containing parts they shouldn’t in the first place, you don’t need to do any extra work to clean them up. The tip of your branch should be the only “messy” part.
3eb7988a1663 4 hours ago [-]
That is a lot of discipline up front. I am sure there are problems which are nicely bucketed, but I usually have to go with the flow and make changes as I see them. I want to keep working with the code, not babysitting version control as I focus on getting the initial version to work.
surajrmal 59 minutes ago [-]
I think it comes down to your ability to plan and understand how the work can be broken down before you try solving it. I often know what every commit will look like before I ever touch the code. I do sometimes learn things and change my mind as I make changes but it doesn't often change my commit structure. I tend to work on a codebase I have 8+ years experience in though. I'm sure it doesn't work in a variety of situations though.
drdrey 3 hours ago [-]
I have finally embraced squashing PRs and realized I wasted my youth trying to write Good Commits.
vermilingua 41 minutes ago [-]
These Good Commits are for the review’s benefit, not necessarily trunk history.
nozzlegear 4 hours ago [-]
As a git rebase enjoyer, I've completely switched over to jujutsu. The whole experience is more ergonomic in my opinion, and the default workflow which I use (using `jj new` to create a new change that clearly delineates work on a different "thing" before I start working on it) fits my mental model much better than the traditional write-then-commit workflow we all grew up with.
nextaccountic 3 hours ago [-]
> Latter commits overwrite work that was done in earlier commits and the story breaks.
> Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess.
Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match
bschwindHN 2 hours ago [-]
Just squash all the PR commits into one when it gets merged to main or whatever your main branch is.
You can revisit the original PR to see the individual commits if you really want.
paradox460 1 hours ago [-]
Jj could do that; it stores an evolog of each change, but currently that's kept local
BobbyTables2 3 hours ago [-]
I don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?
christophilus 2 hours ago [-]
I don't rebase. I just merge and resolve the conflicts. Nowadays, I just have an agent do that for me, and move on with my life.
NamlchakKhandro 1 hours ago [-]
Yes. almost the majority of git users do this. i would say that as an expert commenter, 99.9% of people outside of California do this.
EFLKumo 3 hours ago [-]
This remind me of [jj megamerge](https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...). jj allows concentrating on developing while leaving things for vcs alone, as well as solving vcs things (conflicts) at very beginning (megamerge). Really good.
nvgrw 56 minutes ago [-]
I like how jj allows me to essentially use the same workflow in my personal projects (jj on git) as with my work stuff (jj on piper). That alone is really neat!
codemog 5 hours ago [-]
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.
aggregator-ios 5 hours ago [-]
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.
pkulak 5 hours ago [-]
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.
5 hours ago [-]
nvader 5 hours ago [-]
You can also have you agent use jj with this skill
I tend to just commit whenever I see fit, then at the end I do a `git reset —soft` and write the history that makes sense before pushing.
ninkendo 2 hours ago [-]
I always tell people I use a “git reset” based workflow. I rarely “checkout” branches, I just stay on main, reset hard when switching topics, reset soft when squashing, and I only name my branches on the remote end via “git push origin HEAD:some-branch”.
`git branch` is basically my bookmark tool. I commit for a while, then when I want to remember where I am for later, `git branch wip/topic-a-finally-compiles` or whatever. I can reset hard to it when I want to revert back, or any other topic I need. If I forget to name a branch for a commit, the reflog is right there. Nothing’s lost.
And yeah, a soft reset is basically the ideal way to just say “pretend all my changes weren’t committed yet, starting from $ref” and then I make my single commit for my PR. Easy peasy.
789-ha 2 hours ago [-]
I can’t tell if this is satire. The fact that we have to memorize soft and hard resets was a thing I and everyone else just have to do. But that goes away if you only have commits, so no staging area vs staged changes vs changes on disk, it’s just all a commit and we have a myriad of tools that already know how to deal with commits. Honestly, your workflow as described sounds incredibly compatible with jujutsu, I’d really recommend giving it a shot / another go
everybodyknows 2 hours ago [-]
> A downside to this technique is that there's no guarantee that every commit will compile, which might be a dealbreaker.
To some of us, that's an essential structural criterion. Passing unit-level self-tests may be as well.
xyzsparetimexyz 4 hours ago [-]
With jj I mostly just `jj split -B @`. Nice interactive ui for picking the changes I want into a commit. So many times better than 'git add -p'
singiamtel 4 hours ago [-]
The only thing that stops me from switching to jujutsu is that lazygit already paves through all these paper cuts pretty well, and I'd miss their custom patches feature.
> 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?
stouset 4 hours ago [-]
You can literally jump into a commit and edit its contents directly, and everything is auto-rebased on top.
There are no modal “sorry rebase failed, best of luck” gotchas. There are no “oops I put the wrong thing in the wrong part of the rebase and now I have to abort and start all over” gotchas.
It’s rebase, but without all the extra work, mental overhead, failure cases, and effort.
matheusmoreira 2 hours ago [-]
How does it just auto-rebase everything without failing though? If you edit something later commits depend on, then you get merge conflicts. Are you implying that jj just automatically handles all this?
I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
5 hours ago [-]
9029 5 hours ago [-]
I'd recommend reading the post, it's not that long
raincole 5 hours ago [-]
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.
ai_slop_hater 5 hours ago [-]
git rebase -i kinda sucks once you tried jj.
fragmede 5 hours ago [-]
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.
hu3 2 hours ago [-]
This. I feel jj is some years too late.
It tries to solve a human problem in an LLM era.
LLMs are destined to overcome humans in code merging and change versioning (already did for me).
There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.
surajrmal 52 minutes ago [-]
A lot of humans don't currently trust agents to touch VCS today. I also find that my agent tends to be much better about dealing with jj than it is with git.
mi_lk 5 hours ago [-]
So: Squash everything together then pick each component out by squash -i to an empty commit.
Seems straightforward, wouldn’t call it special
nomel 5 hours ago [-]
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.
incognito124 5 hours ago [-]
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!
hooper 2 hours ago [-]
It's interesting that even clear advantages like `jj undo` are hard to communicate because of this.
ruszki 3 hours ago [-]
The problem with this mindset, that there is zero reason to move away from Git. I can do effortlessly everything with it. There is no incentive. I never said "it would be so good that I would be able to X"... and I didn't find a solution for it quickly. As under this post is obvious as much as under other previous posts, you can do the same things effortlessly with Git. The effort is not that I need to use 2 commands less, but to separate the code (in this specific case), which takes about a 100-1000x more time than typing those 2 extra commands, or really the need to think what kind of commands need to be used in any VCS.
The same problem with vi for example. Which I learned, deeply and for a long time. Maybe I will be break even in a decade or two. And for example, I can code faster than anybody who I know and use vi all the time (or some vi keyset in Emacs or something), not because I type faster, but because I don't need to rewrite my code that many times than them.
The same with jj. I'm happy that it clicks better than Git for some. But I know Git from inside and out. Git was never the bottleneck for me. And really any VCS in the past. If I learn jj, then I don't expect that the effort pays off in a decade or less in the best case. My work's result would be the exact same thing, just with different commands, commands which takes almost no time compared to my other tasks.
bsder 2 hours ago [-]
> I spoke about this before, but jj has the Blub Paradox problem
It's not relevant. Don't try to convert git users--you don't need to. They're fine doing what they do, and the git backend store is acceptable. People who understand how broken git is will gravitate to jj with the lightest of prodding--give them a light poke and then don't harass them further.
The main difference is that I can teach jj (like I could teach hg) to normal people. And, because jj is based on the git store, they can operate in a Github world.
So, just teach jj to people who haven't yet broken their brain with git. Running on the git backend already gains most of the network effect, so don't proselytize the git people.
skydhash 4 hours ago [-]
> Unfortunately, the only way to get it is to spend a week with it, with an open mind
We do get it. But have you ever thought that git inflexible nature and full control is what some people people like?
Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code.
And once upon a time, I preferred history log like the one in the article. But this days (mostly inspired by mailing list development style) I wants the commit in my main log to be either features or bug fixes. Everything else is “wip”, which I will squash. It makes it easier when rewriting history, cherry picking, or just browsing the log.
jolux 4 hours ago [-]
There’s nothing stopping you from using separate changes to emulate the staging area if you want.
The big differences are that the jj approach gives you a commit message for the staging change, and lets you jump to some other commit without extra steps.
skydhash 4 hours ago [-]
I can, but I don’t need to.
jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.
sswatson 27 minutes ago [-]
Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win.
It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.
Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.
jolux 4 hours ago [-]
Totally fair :) personally I used to be a git wizard and I am relieved at how much about it I’ve been able to forget since learning jj, but I understand not everyone has the same experience.
Macha 1 hours ago [-]
Having been often called by coworkers to assist them with their git problems, I can assure you they don’t have a git mental model.
5 hours ago [-]
jonathanyc 5 hours ago [-]
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.
einpoklum 5 hours ago [-]
> 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.
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.
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?
I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
I think I misread you, because you were talking about git vs svn in a way that made it sound like jj was a step backward from git as regards branching, and I got confused.
> I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Right, but you can still name your branches with bookmarks, you’re just not required to. Personally, I tend to use commit descriptions more than bookmarks to keep track of what I’m working on, but this is a personal choice.
> Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
It’s just nicer as a local workflow, to me at least? I can create throwaway branches without having to come up with a name for them. I end up creating many, many more branches than I did in git as a result, which helps me keep my work better organized and my changes more focused when I submit them for others to review (which at least on GitHub, requires a bookmark of course). This is ultimately psychological because obviously I could just make up a name for the git branch, right? But it makes a big difference for me!
Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
Is it easy?
Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.
I dislike this as well. I find it easier to keep track of branches with bookmarks, but my workflow still makes things cumbersome. I am usually working with the "megamerge" branches, and I usually want to add commits to my current branch instead of squashing my edits. However, adding commits means I have to add my commit, move my bookmark up to the branch tip (jj tug?), and then rebase the megamerge branch, versus doing nothing for squashing. I also find that when I mess up, I don't really love using `jj op log` to fix it. I want to not be in an environment where it's this easy to destroy history (I feel like git was on the other end of it).
That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and deletes remote git branches (`jj git push -c` for creation, plain `jj git push` for updates, `jj git push --deleted` for deletions). I do not ever have to think about branch names and it is great!
Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent branches, than scanning through 50 commits, when trying to remember where some work last was, and which is the proper end-point instead of some failed attempt or unrelated change.
Unnamed branches are quite neat - I certainly have a lot more of such than named ones in jj - but as such named branches are, if anything, more important as a result, for separating sequences of changes striving towards a goal, from the sea of smaller experiments.
Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do.
> Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change.
Rewriting it is not wasted time. It is an opportunity to look at what I have written in the plan and check whether I have really executed them, and then rephrase things to be more easily understandable.
> Restricted and summarized is good - easier to find/remember, less fluff in a list.
The first line of a commit message is already a summary of the work done. And you can use actual English instead of trying to awkwardly avoid spaces in your words.
I usually don't have a plan for the end; certainly not what any specific commit would be; sure, I could make one (and either make my future self have to do extra work to figure out what commits with lies in their descriptions actually do, or continuously update the commit message marking what actually exists), but as I said that's basically a waste of time. (if you like comparing with past thoughts, sure, but that's definitely not a necessity for a workflow to be reasonable)
"is/isn't an ancestor of the bookmark" is also just a pretty damn good short-hand for denoting a separation between what's been considered the best attempt at the goal, vs things with known problems or just unrelated to the task.
At the core, this if all of course just a question of workflow; if you go into a thing with a plan, meaningful outlook of a non-vague destination, and without expecting continuous switching back&forth between a dozen other things over the time span the branch is alive, caring less about branches or branch names can perhaps work.
> The first line of a commit message is already a summary of the work done.
But you can't (sanely) use it to reference the branch in a revset, can't find it anywhere other than the full log (that's interleaved and mixed with a bunch of other things that you won't ever need to search for), and actual English just gets in the way for finding it, remembering it, and identifying it in a list.
This alone means that, even if I found interest in massively-ahead-of-time-describing commits, having a sane branch reference is still simply just necessary.
But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that everyone that likes JJ isn't really doing collaboration.
> having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters
In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.
I like Jujutsu so much that I've been working on massive refactors to my tooling in order to support it (example: https://github.com/LoganDark/get-shit-done)
But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.
It feels like Apple vs Linux. Apple being different ... just because (it gives them an artificial moat)
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
> [absorb] splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.
I use absorb fairly often, fwiw. It's great for when I want to make a patch to a commit that will easily absorb into its right place. And I also, sometimes, prefer the more intentional approach where I decide exactly where each hunk will go.
Basically, if you don’t get into that sort of situation with commits containing parts they shouldn’t in the first place, you don’t need to do any extra work to clean them up. The tip of your branch should be the only “messy” part.
> Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess.
Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match
You can revisit the original PR to see the individual commits if you really want.
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.
https://github.com/danverbraganza/jujutsu-skill
`git branch` is basically my bookmark tool. I commit for a while, then when I want to remember where I am for later, `git branch wip/topic-a-finally-compiles` or whatever. I can reset hard to it when I want to revert back, or any other topic I need. If I forget to name a branch for a commit, the reflog is right there. Nothing’s lost.
And yeah, a soft reset is basically the ideal way to just say “pretend all my changes weren’t committed yet, starting from $ref” and then I make my single commit for my PR. Easy peasy.
To some of us, that's an essential structural criterion. Passing unit-level self-tests may be as well.
I see there's a similar project for JJ, but it doesn't seem nearly as polished https://github.com/Cretezy/lazyjj
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
In what way is that different from using `git rebase -i` to edit a commit?
There are no modal “sorry rebase failed, best of luck” gotchas. There are no “oops I put the wrong thing in the wrong part of the rebase and now I have to abort and start all over” gotchas.
It’s rebase, but without all the extra work, mental overhead, failure cases, and effort.
It tries to solve a human problem in an LLM era.
LLMs are destined to overcome humans in code merging and change versioning (already did for me).
There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.
Seems straightforward, wouldn’t call it special
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!
The same problem with vi for example. Which I learned, deeply and for a long time. Maybe I will be break even in a decade or two. And for example, I can code faster than anybody who I know and use vi all the time (or some vi keyset in Emacs or something), not because I type faster, but because I don't need to rewrite my code that many times than them.
The same with jj. I'm happy that it clicks better than Git for some. But I know Git from inside and out. Git was never the bottleneck for me. And really any VCS in the past. If I learn jj, then I don't expect that the effort pays off in a decade or less in the best case. My work's result would be the exact same thing, just with different commands, commands which takes almost no time compared to my other tasks.
It's not relevant. Don't try to convert git users--you don't need to. They're fine doing what they do, and the git backend store is acceptable. People who understand how broken git is will gravitate to jj with the lightest of prodding--give them a light poke and then don't harass them further.
The main difference is that I can teach jj (like I could teach hg) to normal people. And, because jj is based on the git store, they can operate in a Github world.
So, just teach jj to people who haven't yet broken their brain with git. Running on the git backend already gains most of the network effect, so don't proselytize the git people.
We do get it. But have you ever thought that git inflexible nature and full control is what some people people like?
Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code.
And once upon a time, I preferred history log like the one in the article. But this days (mostly inspired by mailing list development style) I wants the commit in my main log to be either features or bug fixes. Everything else is “wip”, which I will squash. It makes it easier when rewriting history, cherry picking, or just browsing the log.
The big differences are that the jj approach gives you a commit message for the staging change, and lets you jump to some other commit without extra steps.
jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.
It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.
Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.
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.