[HN Gopher] I see a future in jj
___________________________________________________________________
I see a future in jj
Author : steveklabnik
Score : 172 points
Date : 2025-10-22 17:21 UTC (5 hours ago)
(HTM) web link (steveklabnik.com)
(TXT) w3m dump (steveklabnik.com)
| joshstrange wrote:
| I guess I see what the author was trying to convey talking about
| Rust/Go at the start but I'll admit it confused the hell out of
| me when we got to Jj (horrible name IMHO but whatever).
|
| Jj is a VCS, it was not at all clear (to me) until I got further
| and I was very confused as to why we were talking so much about
| source control (I thought Jj was a language since the article
| started by talking about Rust/Go).
|
| Apparently Jj can work on/with git repos making it easier to
| adopt incrementally which is neat and the main point of this post
| is that the author is leaving Oxide to go work for a new company
| trying to to create the GitHub of Jj (my understanding at least).
|
| I hope this helps someone else who might be confused like I was.
| steveklabnik wrote:
| Thank you for the feedback! I talk about it so much I feel like
| regular readers of my blog will know this stuff already, but I
| also don't want to leave out important context for others.
|
| I tried to help fix this in https://github.com/steveklabnik/ste
| veklabnik.com/pull/125/fi..., thanks again!
| simultsop wrote:
| If you're asked why Rust. I believe you are always free to
| choose.
| sunshowers wrote:
| The full name is Jujutsu, but I think "jj" did come first. "j"
| is nice because on QWERTY keyboards, not only is it on the home
| row, it is one of the two keys that has a little tactile marker
| (bump) on it.
| Bolwin wrote:
| Since JJ has technically git compat, I think there's 2 things
| needed for it to take off
|
| 1. A good vscode extension (there's two so-so ones that I'm not
| sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing
| something in jj the other day, it didn't even recognize it at
| first. When I reminded it it was a vcs it hallucinated half the
| commands. I ended up figuring it out myself from the docs
| steveklabnik wrote:
| I do think that GUI stuff is important, there's a lot of folks
| who have said "not interested unless there's a magit
| equivalent" which I totally understand. I'm not a big GUI
| person for VCS myself, so I don't feel the same pain.
|
| For LLMs, yeah this is hard for any new project. I use Claude
| Code, and it does a decent job with jj, it only tries to do git
| stuff sometimes. I haven't asked ChatGPT about it though, I'll
| have to experiment with it myself.
| Bolwin wrote:
| Since they guy behind it works at Google, I wonder if gemini
| is better at it.
| steveklabnik wrote:
| I don't think Google is best though of as a singular
| entity, I'd very seriously doubt that if it is, it's
| because of this.
| victorbjorklund wrote:
| Doubt the gemini team handpicks training material based on
| wether the author works at google or not. Doubt they
| handpick it at all.
| p_l wrote:
| Both Claude and Gemini can be integrated reasonably by
| informing them how to use JJ commands or even through MCP
| nonethewiser wrote:
| You're kind of right about LLM knowledge but the implication is
| funny. We just cant be expected to learn new things without
| LLMs...
| klardotsh wrote:
| What a terrible world we're barrelling towards when "LLMs
| don't know about it" is considered a blocker towards
| something taking off. Read a blog post, read a man page
| (which GP says was indeed their solution), or just play with
| the dang tool, I assure you these things are still possible
| without the assistance of a predictive text engine helping
| you!
| senderista wrote:
| One problem is that Stack Overflow isn't being updated with
| questions about new tools because it's been crowded out by
| LLMs, so the LLMs can't train on these nonexistent new
| questions/answers.
| dgunay wrote:
| > LLM knowledge
|
| Give it time. Once JJ resources enter the dragnet of future
| model datasets, LLMs will get better at regurgitating it.
| nicoburns wrote:
| > I ask gpt-5 about doing something in jj the other day, it
| didn't even recognize it at first.
|
| Using VC commands an LLM generates for you sounds like a pretty
| terrible idea anyway. What if they delete your data? Why not
| spend 5 minutes searching for information written by a human?
| amenhotep wrote:
| jj undo :)
| kelnos wrote:
| At the risk of being unreasonably negative, stuff like this just
| makes me feel... tired. Git is... fine. I'm sure it doesn't solve
| every problem for everyone, and oh boy does it still have many
| rough edges, but it works and (as the article points out), git
| has won and is widely adopted.
|
| I've extensively used CVS and Subversion in the past. I touched
| Mercurial and Bazaar when I ran into a project that used it. I
| remember in the CVS days, SVN was exciting to me, because CVS was
| such a pain to use, in almost every way. In the SVN days, git was
| exciting to me, because SVN still had quite a few pain points
| that poked me during daily use. Again, yes, git had and has rough
| edges, but nothing that would make me excited about a new VCS, I
| don't think.
|
| Maybe I'm just getting old, and new tools don't excite me as much
| anymore. Learning a new tool means spending time doing something
| that isn't actually building, so my eventual use of the new tool
| needs to save me enough time (or at least frustration, messily
| converted into time units) to balance that out. And I need to
| factor in the risk that the new tool won't actually work out for
| me, or that it won't end up being adopted enough to matter. So I
| think I'll wait on jj, and see what happens. If it ends up
| becoming a Big Deal, I'll learn it.
| steveklabnik wrote:
| I think being conservative about tool use is totally fine! I'm
| actually pretty conservative about most of the tools that I
| use.
|
| The goal of this post wasn't really to convince anyone on why
| they may want to give jj a shot, more of just a post about how
| I think about technologies I may want to spend my limited time
| on this planet working on, and announce that I'm making a move.
|
| I don't think that you're being unreasonably negative. I think
| it's crucial for technologies to understand that your position
| is basically the default one, and that you need to offer a real
| compelling reason to choose a new tool. For some people, jj has
| enough of that already to bother with choosing, but I think the
| real power is in things that aren't widely available yet. Hence
| the need to go build some stuff. It's early days! Not even 1.0
| yet. It's very natural that most people do not care at this
| stage.
| jimbokun wrote:
| One thing not mentioned in the article: what advantages does
| jj offer over plain git?
| steveklabnik wrote:
| So for me, the most compelling thing about jj is that it is
| somehow simpler than git, while also being more powerful
| than git.
|
| What I mean by simpler is, there's fewer features, which
| makes things easier to pick up, because these features fit
| together in a way that's more coherent than git's. By more
| powerful, I mean jj lets me regularly do things that are
| possible, but annoying and/or difficult in git.
|
| I loved git. I was never the kind of person who thought its
| CLI was bad. But then, when I found jj, I realized why
| people thought that.
| jimbokun wrote:
| So better UX while keeping git's solid internals?
|
| Makes sense. Developers I know have been wanting that.
| steveklabnik wrote:
| It's technically a bit more than that. JJ is its own VCS,
| with pluggable backends. Google has a closed-source Piper
| backend, the git backend is the only real open source
| backend. But at high level, it's fine to think about it
| in that way, yeah. I tend to think about it as being more
| "able to work on git repos" than as a UI.
| warwren wrote:
| I can't hear Piper backend without thinking about Pied
| Piper
| SoftTalker wrote:
| Not the only project that's working on that.
|
| https://www.gameoftrees.org/
| wk_end wrote:
| As someone who loves git, has always thought the
| criticisms about its interface were overstated... but
| also feels like it maybe has too many incoherent ways of
| doing things, this is the best sales pitch I could've
| asked for (and I came to the comments to ask for a sales
| pitch). Thanks - I'll try jj out the next time I start a
| hobby project.
| steveklabnik wrote:
| You're welcome, and feel free to let me know how it goes.
| There is an adjustment period, for sure, and (in another
| eerie parallel to Rust) some folks try it, bounce off,
| and try again later, and it sticks then.
|
| The auto-commit behavior was one of my biggest concerns
| when starting, but it turns out that when combined with
| other things, I'm a huge fan now, for example.
| lowboy wrote:
| Another good sales pitch is `jj undo`[0]. It puts the
| repo back to previous state, regardless of what the
| mutative operation was. It's a powerful and simple safety
| net that unlocks experimentation.
|
| It does this by adding an new operation on top of the
| operation log[1], so you don't lose repository states by
| moving up + down the op log. There's a corresponding `jj
| redo` as well.
|
| 0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-
| undo
|
| 1: https://jj-vcs.github.io/jj/latest/operation-log/
| socalgal2 wrote:
| jj undo is great but it's a one time thing. You can't do
| jj this, jj that, jj other, jj undo, jj undo, jj undo
| AFIACT. You have to look into the op log and jj op
| restore for that. It's nice you can get back to where you
| were though.
|
| The biggest issue for me is it requires active change
| management (or feels like it). In git I do `git checkout
| foo` then I start editing. If I want to see what may
| changes are since foo then `git diff` tells me. With jj
| though, `jj edit foo` is the to git, state of the repo
| ALL changes to foo. So any new edits are invisible. So,
| instead of `jj edit` I have to do `jj edit` `jj new`,
| then later squash those into foo
|
| I know there are similar cases in git but I guess I'm
| just used to git so I wasn't using those cases.
|
| that said, I'm mostly enjoying jj. Though quite often i
| get a conflict I don't understand. Today I got 2 and it
| told me choose A or B. I did `jj diff -r A -r B` and it
| said no diffs. If no diffs aren't there no conflicts? I'm
| sure someone gets it but it was annoying to just have to
| pick one to abandon
| mkeeter wrote:
| > jj undo is great but it's a one time thing.
|
| For what it's worth, this changed in v0.33.0:
|
| > jj undo is now sequential: invoking it multiple times
| in sequence repeatedly undoes actions in the operation
| log.
|
| (release notes: https://github.com/jj-
| vcs/jj/releases/tag/v0.33.0)
| steveklabnik wrote:
| I'm not sure if it's a typo, but you don't need to edit
| and then new, you can just new. It's a good habit to get
| into as a replacement for checking something out.
|
| I'm not sure what happened in your conflict situation
| either, that does sound frustrating.
| lowboy wrote:
| > You can't do jj this, jj that, jj other, jj undo, jj
| undo, jj undo AFIACT
|
| You can as of v0.33.0[0]. Previous behaviour was that `jj
| undo; jj undo` would leave you where you started (it
| undid the undo).
|
| > The biggest issue for me is it requires active change
| management (or feels like it). In git I do `git checkout
| foo` then I start editing. If I want to see what may
| changes are since foo then `git diff` tells me. With jj
| though, `jj edit foo` is the to git, state of the repo
| ALL changes to foo. So any new edits are invisible. So,
| instead of `jj edit` I have to do `jj edit` `jj new`,
| then later squash those into foo
|
| I'm not 100% clear on what you mean here, but a few
| things that might help:
|
| 1. In jj you don't "checkout" a branch, you edit a
| specific commit. That commit might be pointed to by a
| bookmark but it doesn't have to be. A jj bookmark is
| roughly equivalent to what git calls a branch. Note that
| a git branch, and a jj bookmark are just pointers to a
| commit, as illustrated here[1]).
|
| 2. If you want to resume work on a branch/bookmark
| instead of `git checkout BRANCHNAME` you'd do `jj new
| BRANCHNAME` which puts a new commit on top of the commit
| and sets it as a working copy.
|
| 3. Bookmarks don't auto advance like they do in git. So
| adding new commits on top of a "branch" will leave the
| bookmark where it is until you `jj bookmark set/move` it.
| So you could squash commits down into the "foo" bookmark,
| but you could also move "foo" to point to subsequent
| commits.
|
| 4. Not sure what you mean by edits being invisible, but
| if it's seeing a diff from main to the tip of your branch
| (with a change id of ex. XYZ) it would be `jj diff -f
| main -t XYZ`.
|
| 0: https://github.com/jj-
| vcs/jj/blob/main/CHANGELOG.md#0330---2...
|
| 1: https://social.jvns.ca/@b0rk/111709462585184810
| nonethewiser wrote:
| can you directly get the parent branch of a branch in jj?
|
| This is one thing that I constantly find myself wishing
| was in git but inevitably resign myself to knowing "thats
| just not how git works."
| steveklabnik wrote:
| Could you spell out slightly more what you mean? I'm not
| 100% sure what "get" means.
| 1718627440 wrote:
| I think they mean what other branch some branch was
| originally branched off from.
| baq wrote:
| I don't think you ever need to do this, jj tracks changes
| much better than git, assuming I understand your
| question. E.g. you can rebase a whole local change dag
| based on a commit from origin with a single jj rebase -b
| and it'll move bookmarks (git branches) correctly.
| mckn1ght wrote:
| Right, "parent branch" implies a tree structure, but git
| is a DAG.
|
| You might have a specific workflow such that you can
| actually answer your question, but it won't generally
| apply to all repos.
|
| Since a branch is really just a label for a specific
| commit, which may be at the end of a chain of successive
| parent commits, a branch isn't really a first class
| structure, but a derived one.
|
| You can get the fork point of a branch, which is a common
| ancestor commit shared by another branch, but that fork
| point is a commit and may not have a branch label. That
| commit can have any number of other branches going off of
| it: how would you decide which one is the parent vs just
| another sibling?
|
| My assumption after looking at jj is that it is not as
| complicated as git _yet_. Give it time. It's also not
| even as simple as git for many tasks, based on their own
| docs: https://jj-vcs.github.io/jj/latest/git-command-
| table/
| petre wrote:
| Git's CLI is awful compared to fossil or even mercurial.
| Jj seems like an improvement over git, but it lacks a web
| UI like fossil has. It's very useful. Basically like a
| self contained github lite, only without the needless
| complexity, the enterprise bs, the annoying login
| process, tokens, passkeys, brain damaged permissions
| system etc.
| kelnos wrote:
| Sure, definitely, sorry for being a bit off-topic, clearly
| this was about you and your plans and not intended to be
| about jj itself.
|
| Having said what I said, I _do_ find new tools to be
| interesting, and I do hope jj ends up being successful. I 'm
| always happy to be surprised by something that fixes problems
| that I didn't consciously know I had, or that adds new
| features or work modes that make my life easier in ways that
| never would have occurred to me in the first place. I was a
| pretty early git adopter, and it works great for me, but I'm
| sure a decent chunk of that is because I understand how it
| works under the hood, even if it often doesn't present a
| great UX.
|
| And even if jj doesn't eventually surpass git's popularity,
| it's great to have other options, and avoid monocultures.
| pythonaut_16 wrote:
| Fair points. I'm also generally happy with Git myself.
|
| I've been exploring JJ mainly for its slightly different
| approach to change tracking (~every change gets tracked, at
| least initially, rather than just commits).
|
| Stacked PRs also look interesting but I haven't had an occasion
| to try them out yet.
| jakub_g wrote:
| The good thing is that a new player entering the arena allows a
| fresh look at certain problems, and some solutions then get
| backported to the OG project. I've read it already happened
| that jj inspired some changes in git.
|
| Same happened e.g. with nodejs getting deno and bun around,
| which allowed to break nodejs' inertia on many problems that
| the others have solved.
| baq wrote:
| I used to think this, too. Tried jj a few times before it
| clicked.
|
| It's very liberating in some ways, in others it's simply no
| worse than git. You can do everything you can do with git, but
| some of those things don't require multiple steps or n repeats
| of the same action. jj rebase + commitable conflicts + jj undo
| = freedom and peace of mind.
| weinzierl wrote:
| I used to think the same way about jj not too long ago. I even
| wrote a few comments here similar to yours, but since then I've
| changed my mind.
|
| For me, the turning point was realizing that jj actually eased
| some of the frustrations I had with our rebase workflow at
| work. It took a while for it to click, but now I wouldn't want
| to go back
| riffraff wrote:
| May I ask what is your rebase workflow at work?
|
| In my day to day, its basically "git pull --rebase repo
| branch", plus some interactive rebate to squash commits, and
| it's not particularly frustrating, so I'm curious what you're
| doing that we're not.
| weinzierl wrote:
| Basically the same except in some projects we are not
| supposed to squash. So, sometimes we end up with long long
| histories to be rebased onto other long histories.
|
| rerere only helps so much with conflict resolution but with
| jj I think it is as painless as it could be.
| dxdm wrote:
| I think yours a perfectly reasonable stance, and I often feel
| the same way. And all this complaining about git is getting
| tiresome, especially if you had to deal with its predecessors.
|
| FWIW, I still tried out jj and found it a joy to use. I use it
| all the time now. Most of the time, it not only gets out of
| your way, but rolls out the red carpet. I'm saying that as
| someone who knows their way around the git command line. t's
| like replacing your trusty old remote control with a new one
| where the buttons are well labeled, ergonomically placed, that
| lets you do entirely new useful things, and it has a universal
| back button that just works.
|
| Maybe jj is an especially good fit for my way of working, but I
| do think that it is a real, actual improvement for everyone.
|
| And it's super easy to pick up anytime. So yeah, I think you're
| doing it right! Sit back and let it come your way. From what I
| can see, there's a pretty good chance that it will.
| kzrdude wrote:
| I learned all of cvs, svn and then later git when getting into
| Linux and Open Source. Based on my early experience of multiple
| systems, I'm very surprised that git has dominated and lasted
| this long already!
| jrockway wrote:
| jj is actually so good though. People don't need to know you're
| using it, which is why it's nice.
|
| A problem I run into when working with other people is that
| code reviews take forever and I need to build on top of them.
| Code gets merged while it's being reviewed, and it becomes a
| burden to keep rebasing your stack of PRs. It's also difficult
| to do things like designing each PR against the main branch,
| but testing all 3 of them together. (Sometimes you want to
| write the docs / take screenshots as though all your features
| are merged as-is.) jj makes all this trivial. You tell it what
| you want and it does it without involving an index or working
| copy or interrupting you to resolve conflicts.
|
| I've found that it really makes me less annoyed when working
| with other people. I don't know why it takes people longer to
| review code (or to even open the review request) than it takes
| me to write things. But it does, and jj is what keeps me sane.
|
| To be fair, I also use it on personal projects because
| sometimes you have 3 things you want to try at once and they're
| not related to each other. Upstream isn't going to change
| without your understanding, but it's still mechanically
| something to maintain the rebases on those 3 branches. jj just
| makes this burden go away.
|
| Having said that, I don't know why a "jjhub" is needed. Github
| seems fine. jj's just a UI for git.
| constantius wrote:
| I have a question and you might have an idea about this:
|
| I have a workflow where I have my main and a bunch of
| branches that are children of other branches. So: main,
| branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably
| not a good workflow, but that's what I do.
|
| I keep editing old commits in my branches to have clean,
| atomic commits, which fucks up my branch structure and I need
| to cascade-rebase everything manually.
|
| Do I understand correctly that jj does it automatically?
| steveklabnik wrote:
| That's correct, it will do the cascade rebase of everything
| automatically.
| conradludgate wrote:
| I use git but I instead just keep all PRs stacked on top of
| each other and rebase when one is merged. If something is
| easy to review I push it down the stack. If something is
| harder to review I keep it at the top of the stack.
|
| I don't open a PR for each commit, and we use squash commits
| at work which makes it harder to have this workflow but it
| still works fine for me.
|
| I rebase only the leaf PR, and I have update-ref enabled to
| update the branch refs of all other branches in the stack. It
| works well. The only manual process is that I have to
| manually force push each branch afterwards.
|
| Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature
| when rebasing (which is missing in jj) to make sure the stack
| stays in a good state
| kolme wrote:
| I've also worked with CSV (barely) and SVN (more extensively)
| and I was blown away by Git.
|
| You can have real branches! Many of them! You don't have to
| manually merge them! It's decentralized, you can have multiple
| origins, it lets you work offline! The list goes on and on.
|
| There were _many_ compelling reasons to switch to Git. But for
| all the articles about jj out there, I 've never read _any_
| compelling reason to switch to jj. "It easier", "the commands
| are somewhat more ergonomic"... that's all?
| turtlebits wrote:
| Ergonomics are everything. Its why there are zillion IDEs,
| terminal apps, keyboards, mice, etc.
|
| Hot take, but I personally hate git and almost always rely on
| a GUI tool or IDE integration to interact with it.
| dagenix wrote:
| One thing JJ has that git doesn't is the concept of first
| class conflicts. In JJ, rebasing or merging never fails, but
| it might record a conflict to resolve later. Git, on the
| otherhand, forces you to drop we everything to resolve
| conflicts immediately. It sounds like a small thing - but in
| my experience, being able to resolve conflicts later when I
| feel like it is absolutely amazing and really helps reduce
| context switching.
| jauntywundrkind wrote:
| I personally feel quite capable at git and am not looking for
| another flow or tool.
|
| But. I think it's incredibly useful for organizations to have
| patterns for how they use git. There can be huge variance! And
| there's so many people who don't feel comfortable doing
| interactive rebases (of their feature branches), or other
| serious monkeying with history.
|
| (I also think jj's flows are incredibly good about avoiding
| accidental loss of work in a way that git can be extremely
| dangerous at.)
|
| I think there's a ton of value to having more of a pattern than
| the free-form jamming that git gives us. The real value I see
| in jj is that it's more than the toolbox of things git gives
| one: it's something more learnable, teachable, and directed
| than git. And it seems to do it pretty well, with style, and
| less monkey business. I'm still super greenhorn at jj, and
| honestly lacking the need for it, but I'm excited to see it
| come along. Especially since it is compatible with so many
| other VCS.
| pityJuke wrote:
| Off-topic: I found it very surprising the Logical Awesome website
| still works.
| steveklabnik wrote:
| I'll be honest, I did too. No https cert makes it give a
| warning in Chrome, which I had expected to just be a 404, and
| was surprised when it actually worked!
| tomstuart wrote:
| Congratulations on the new adventure, Steve, and good luck!
| davidkunz wrote:
| jj describe -m "Good luck, Steve!"
| drcongo wrote:
| Congrats on the new role, sounds exciting - looking forward to
| seeing where it goes!
| steveklabnik wrote:
| Thanks so much!
| baq wrote:
| I'm just sad pijul doesn't get the same attention or love from
| the community. It desperately needs an ability to colocate with
| git.
| mirashii wrote:
| I think that the ability to collocate with fit is really the
| thing that makes even evaluating the use of jj feasible in many
| organizations. To consider pijul, it requires throwing away all
| of your forge setup, configuration, permissions, backup,
| disaster recovery, as well as updating every CI pipeline.
|
| In a very real way, git won, and the inertia behind git is
| higher than it was for any VCS tool before it, and so just
| being better isn't going to be enough, you'll also need to
| interoperat.
| dagenix wrote:
| I strongly suspect that its not feasible to colocate pijul and
| git. git and jj are based on snapshots, while pijul is based on
| patches. They have very different models.
| bagxrvxpepzn wrote:
| If JJ takes off it won't be for any technical or logical reason.
| It will be because the world of internet programmer media (hn, x,
| youtube, reddit, mastodon, lobsters) will be saturated with JJ
| tutorial edutainment targeted at people who need AI to vibecode
| HTML / CSS.
|
| There are no substantial technical or usability reasons to switch
| to JJ from Git and it's impractical for most working programmers
| to switch. This is a neutral impersonal opinion that is virtually
| a fact. I wish the people who will decide to dedicate the
| precious few years of their life to JJ the absolute best but I
| hope that they decide to do so only after understanding and fully
| digesting the aforementioned perspective.
|
| My well-intentioned recommendation to Steve, because I've been
| there, is: If you want to avoid feeling like you've wasted your
| life in a few years on code that doesn't live up to its promise
| and is essentially no different than the code that already exists
| in Git (and Hg, Pijul, Fossil, etc.), focus on something whose
| main appeal is more than social, i.e. "This would be so great if
| everyone used it!" Otherwise you're just working on a popularity
| contest. Remember this comment.
| sunshowers wrote:
| > There are no substantial technical or usability reasons to
| switch to JJ from Git [...]. This is a neutral impersonal
| opinion that is virtually a fact.
|
| I respect your opinion, but I don't think it's a fact and I
| couldn't disagree any further with it. I wrote a whole
| testimonial about why I love jj (first one there): https://jj-
| vcs.github.io/jj/latest/testimonials/#what-the-us...
|
| > it's impractical for most working programmers to switch
|
| I don't know what you mean here. I think it's quite practical
| to switch to jj, and people switch over all the time. Some
| people are going to be earlier adopters than others, but the
| early adopters can bring others along (as I've been lucky to do
| at Oxide).
|
| > focus on something whose main appeal is more than social
|
| Steve and I both think that Jujutsu's appeal is _far_ more than
| merely some bandwagon effect. I do think that social appeal is
| an important part of making a project succeed, and that
| projects without substantial technical merit win due to social
| appeal all the time, but Jujutsu has both! It 's amazing!
| bagxrvxpepzn wrote:
| > I respect your opinion
|
| Thank you for charitably responding to the substance of my
| comment and especially not whatever tone you may have
| perceived. I appreciate you.
| mirashii wrote:
| > There are no substantial technical or usability reasons to
| switch to JJ from Git and it's impractical for most working
| programmers to switch. This is a neutral impersonal opinion
| that is virtually a fact.
|
| Not a thing in here is true, especially not objectively true.
| As neutral as you may believe yourself, it might be a good time
| to step back and reexamine your priors that led you to state so
| confidently that there's no usability reason to switch in
| particular.
| bagxrvxpepzn wrote:
| > it might be a good time to step back and reexamine your
| priors that led you to state so confidently that there's no
| usability reason to switch in particular.
|
| The key word I used is "substantial." The usability
| improvements over Git are marginal and if they ever become
| non-marginal, they can relatively easily be added to git.
| This is what my comment is getting at. The only essential
| difference between Git and JJ is that they are different
| fiefdoms. There is no substantial technological difference.
| It's just two different social factions with marginally
| different opinions about how to type CLI commands.
| andrewaylett wrote:
| Changesets, the op log, first class conflicts, no staging
| area.
|
| JJ might produce commits that can be stored in Git, but the
| affordances are _different_. If Git wants to adopt them, it
| becomes no longer Git.
|
| On the other hand, I'm happily using JJ while everyone I
| collaborate with is using Git. JJ doesn't need to "win" to
| be useful, it just needs to be useful enough that the
| people who maintain it continue to maintain it.
| Valodim wrote:
| > There are no substantial technical or usability reasons to
| switch to JJ from Git
|
| sounds like someone hasn't used jujutsu
| dxdm wrote:
| > There are no substantial technical or usability reasons to
| switch to JJ from Git and it's impractical for most working
| programmers to switch.
|
| Not in my experience. jj is easy to pick up and a joy to use. I
| like git. I deeply appreciate git. But git can feel like snow
| shoveling sometimes, while in jj things just click into place.
|
| jj is freeing, because things that were a hassle before are now
| easy, and other things that were impossible are also easy.
|
| I know there's a lot of hype around for a lot of things, and I
| get grumpy from all of it. Jujutsu is one of the few things
| that actually deserve the praise being heaped on them.
|
| You may disagree, of course. But I hope that some day, you'll
| have reason to be happy about this tool, instead of feeling...
| whatever touched you off like this.
| ljm wrote:
| This comment could have been written when people were pushing
| to SVN repos on SourceForge when Git was becoming the next big
| thing, enough for a competitor to founded.
|
| Yet still, the status quo is not Subversion and SourceForge,
| both of which have been relegated to antiquity, but git and
| GitHub.
|
| Will something else unseat git and GitHub in the coming years?
| And will it be Jujutsu or some other innovation on version
| control?
|
| Who knows, but I see no need to be so dismissive of somebody's
| passion in such an arrogant way.
| BeetleB wrote:
| > There are no substantial technical or usability reasons to
| switch to JJ from Git
|
| Every magit user disagrees with you.
|
| > and it's impractical for most working programmers to switch
|
| This very much sounds like someone who has never even tried jj.
| Tell us: What makes switching impractical?
|
| > My well-intentioned recommendation to Steve, because I've
| been there, is: If you want to avoid feeling like you've wasted
| your life in a few years on code that doesn't live up to its
| promise and is essentially no different than the code that
| already exists in Git (and Hg, Pijul, Fossil, etc.),
|
| Is Steve even a developer for jj?
| steveklabnik wrote:
| I have not contributed to jj directly basically at all yet:
| https://github.com/jj-vcs/jj/commits?author=steveklabnik
|
| I am assuming that this new job will change that.
| bitwize wrote:
| I was thinking, it'll probably catch on like Omarchy did,
| except it's written in Rust, so... little chance of it being
| milkshake-ducked.
|
| But as we say on Hackernews, there are two kinds of people with
| respect to jj: those who love it, and those who haven't tried
| it.
|
| Doing the same thing, but with better usability, is immensely
| valuable. Remember, Hackernews thought Dropbox was "just"
| ssh+rsync, but they made a billion dollars making that easy.
| christophilus wrote:
| I've tried it. I don't love it or hate it. It's more of a
| "meh". I can see how it'd be nice if I was disciplined about
| my commit history, but I tend to be fine with chunky, clunky
| git. I don't spend as much time curating perfect commit
| history as jj fans seem to.
| adamwk wrote:
| I joined the sapling/subversion company this year, but haven't
| had the chance to use jj. But given its resemblance I must say
| sapling has been great. Much more intuitive than git, and I find
| commit stacks much easier to follow than branches. I do wonder
| how it will work without the level of support of Meta, since you
| won't have the same commit stack review UI (basically a series of
| pull requests being reviewed at the same time). So something like
| what this author is working on is needed.
| steveklabnik wrote:
| Yeah, sapling and jj are fellow travelers, for sure :)
| jmercouris wrote:
| After reading the article, the technical merits of `jj` are
| completely unclear.
| steveklabnik wrote:
| Yes, that was not the goal of the post. There's some comments
| about this in this thread though, here's the first one of mine:
| https://news.ycombinator.com/item?id=45673808
| svat wrote:
| That URL https://news.ycombinator.com/user?id=steveklabnik is
| a link to your user profile.
| steveklabnik wrote:
| Whoops, managed to fix it. Thank you!
| weinzierl wrote:
| I think the real news is that some people have started to build
| what might become something like a _" jjhub"_.
|
| https://ersc.io/
| steveklabnik wrote:
| I think 'jjhub' is a decent immediate first approximation, and
| is often how I've started out talking about it with people. At
| the same time, we have to offer real value here, as you can
| already use jj with github (and I have for a long time now), so
| there's more to it than that. But yes :)
| davidkunz wrote:
| What I would love:
|
| - Everything locally stored in the repo: PRs, comments,
| issues, discussions, boards, ... - CLI first - Offline first
| (+ syncing) - A website for hosting/presentation
| steveklabnik wrote:
| Noted :) In another comment I linked to beads, which is a
| cool project to keep your issue tracker in your repo, but
| that's just a personal thing, no comment on what the
| company plans to do (or not) in this area.
| ElectricalUnion wrote:
| So you want Fossil?
| herpdyderp wrote:
| Another reason to leave GitHub and their weekly downtime!
| benhurmarcel wrote:
| There's this as well: https://blog.tangled.org/stacking
| lima wrote:
| Gerrit also maps really nicely to jj concepts, and there is an
| accepted RfC to add support for Jujutsu change IDs to Gerrit.
| mh9r wrote:
| I tried Jujutsu in the last day and was going through your
| tutorial. I really liked the experience and can see some
| potential. I also got the feeling that there is a missing puzzle
| piece. For example, do I get any benefit from the change id if I
| push to GitHub for PR review?
|
| I guess you benefit from some of the good parts only with the
| Google internal Piper backend, at the moment. So I'm curious
| about the ideas and plans you have at ERSC.
|
| But what I'm also really yearning for is having a distributed
| asynchronous/offline-first code review flow built right in. The
| distributed nature of git somehow got lost with PRs or MRs in
| GitHub & Co.
| steveklabnik wrote:
| Glad to hear you enjoyed it :)
|
| > do I get any benefit from the change id if I push to GitHub
| for PR review?
|
| As of right now? Not really. The details are more complicated,
| but basically, if your project doesn't like the behavior of
| github when it comes to comments + editing commits, and wants
| you to tack on new commits instead, we can't change that
| behavior. However, https://github.com/LucioFranco/jj-spr can,
| in some situations, give you some of this experience. If your
| project is okay with editing commits, then it can help you
| locally, sure.
|
| However. In an interesting turn of developments, GitHub's new
| SVP just tweeted that he's likes jj and is interested in adding
| stacked diffs to github. I don't know how this squares with
| their "no new features for 18 months" thing, but we'll see!
|
| > But what I'm also really yearning for is having a distributed
| asynchronous/offline-first code review flow built right in.
|
| It's not code review, it's issue tracking, but I've been using
| https://github.com/steveyegge/beads this week, and I think it
| might be the first "put your issues in your repo" system I
| actually enjoy. It says it's built for AI stuff, but like, you
| don't have to use AI with it.
| j2kun wrote:
| > I also don't mean to imply that everyone at Google is using jj,
| but the contingent feels significant to me, given how hard it is
| to introduce a new VCS inside a company of that size.
|
| I don't mean to imply that Google is fickle, but anything besides
| Google's perforce fork is deprecated every few years. We used to
| have a proper git wrapper, then mercurial+extensions, now jj is
| supposed to replace the mercurial thing, all in 7-ish years?
| steveklabnik wrote:
| The intention with this is to also deprecate the Perforce fork,
| in my understanding.
|
| But yeah, it's been a lot. Frankly even harder to keep track of
| from the outside!
| Pet_Ant wrote:
| One thing I've wanted is the ability to group commits into a mega
| commit. So the history of little changes remains, but as you are
| scrolling you don't see all of them.
| steveklabnik wrote:
| This is an interesting idea... jj has a templating language,
| but it's not stateful, so you couldn't like, hide some commits
| based on other commits, for example. But I'll file this away...
| eddd-ddde wrote:
| You could probably use bookmarks for this.
| stonecharioteer wrote:
| Steve, Rain, please call it dojo.dev or something before jjhub
| catches on.
| steveklabnik wrote:
| Rain's not working at ERSC, but we won't be naming the product
| jjhub, don't worry.
| zephraph wrote:
| So excited for this. I talked to the ERSC folks last year about
| joining but it was a little early for me. Still incredibly
| excited about what they're building and glad to see one of my
| favorite people joining the effort.
|
| Steve, if you come to NYC hit me up!
| steveklabnik wrote:
| Thank you! I'll try to remember that.
| TinkersW wrote:
| Does it work with large binary files and not choke like git?
| Cause git may have won for webdev etc, but in some industries
| such as gamedev, Perforce is the king... git is barely used at
| all because it can't handle binary files worth a damn(yes I know
| about the large file extension, no it isn't sufficient).
| steveklabnik wrote:
| Right now, nothing special. But this is very much an area
| that's known about and something may happen in this area, we'll
| see.
___________________________________________________________________
(page generated 2025-10-22 23:00 UTC)