13 ms·

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out of inertia. Of course both of these do happen—nothing is perfect—but they are by far the exception. From my own personal anecadata, I have seen a 100% conversion rate from everyone who gave it a serious try. I encourage you to let today be the day that you decide to try it out. It is far less effort to make the switch than you probably think it is: I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. You will quickly be more productive and you will find yourself amazed at how you ever got by without it.

0x457 1y ago
Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
- Valodim 1y ago
  There were (are?) people who say the same thing about svn
  - 0x457 1y ago
    Sure, but in this case, git being distributed is what sold it for me. I've switched off svn as soon as I've learned of git.
- globular-toast 1y ago
  I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting. I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.
  - tcoff91 1y ago
    It’s really nice to use the —-first-parent flag with bisect.
    - globular-toast 1y ago
      Yeah this is good if you, for some reason, rebase then merge without fast forwarding. I never understood doing this. If I'm going to be ignoring those commits when bisecting then they are useless commits just using up disk space IMO. Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.
      - 1718627440 1y ago
        For me a merge is about grouping commits, when you have just a list of commits, the list can be very long. That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.
        globular-toast 1y ago
        The whole point of bisect is to make it quicker to find a point in a potentially long list of commits. Finding the feature first then bisecting within the branch is only going to make it slower, and requires you to manually restart the bisect. I use the commit message to add ticket numbers to things to group commits.
        1718627440 1y ago
        The commits surrounding them (logically) are probably also relevant, which you will find easier when you have grouped commits by features. I prefer to have everything in a single source of truth (git), so everything is in commits. Your tickets are my merge commits.
- ykonstant 1y ago
  Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.
  - falconertc 1y ago
    Bisect is a very cool feature that I used once over 5 years ago. The collection of git tools that I use often is very small. I've found that the more experienced I got with git, the less I found myself in scenarios where I needed git's more complex tools.
    - theLiminator 1y ago
      Hmm, bisect is definitely not one of those.
  - 1718627440 1y ago
    Yes not using bisect, seams like you do all the work to record information, but then never use that information to save work?
    - 0x457 1y ago
      May I use how often and why you use bisect? I don't remember the last time I needed bisect. Well, I also don't work in linux kernel sized repos, so there is that.
      - 1718627440 1y ago
        > May I use Was that 'may I ask'? Not that often, but not seldom. Its useful if you have a bug, that isn't obvious where it comes from, but easily testable. Then you just write a test and let git figure out where it comes from. The test doesn't need to be automatable. I also used it for firmware that needs to be flashed and the bug effected in an LED blinking incorrectly. I still saved a lot of time.
        1y ago
- anticodon 1y ago
  I used bisect once in my life but it was extremely helpful. Without it I'd spend weeks trying to find regression. With bisect I found and fixed it in under 1 hour. It's a command that is needed rarely but there's no replacement for it in some situations.
  - pclowes 1y ago
    I am confused by this, isn't Bisect just some git ergonomics with respect to flagging a checked out commit as a success failure and then checking out the next midway commit depending of if it was a success/failure to enable classic binary search? It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I like the ergonomics but only use it once every couple years.
    - anticodon 1y ago
      Agree, probably could be done in any other VCS as well, including CVS. But only possible if you actually use VCS and use it properly.
bjackman 1y ago
Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me. Even though my main work involves quite a lot of annoying rebases which is where JJ really seems to shine. I dunno I guess it's just that a) I've really mastered git and have a deeply-rooted workflow in it and b) despite my project involving annoying rebases, version control still isn't very high on the list of problems I have. So yeah I'm basically bullish on JJ as a technology but I think movement from Git is inevitably gonna be slow and steady.
- stouset 1y ago
  I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.
  - bjackman 1y ago
    Yeah I guess it confirms your point in a way too. There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all. So yeah this is still basically a recommendation for people to try JJ!
- sethammons 1y ago
  Curious, I was under the impression that Google was all a monorepo, but your phrasing suggests that there are others. As my company is pushing for a monorepo, I'd love to know what causes someone at big G to not be in the monorepo. Thanks for any insights you can help me with!
nephalegm 1y ago
I started doing jujitsu a few months ago. The title of the article and this top comment had me bewildered until I remembered what jujitsu was in this space LOL
esafak 1y ago
Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.
- Disposal8433 1y ago
  I've always hated the git CLI, and that's why I used Jetbrains tools or Sublime Merge. Now that I switched to jj (colocated with a get repo, very useful), I went back to using the CLI again for jj and I don't miss the graphical tools.
  - exclipy 1y ago
    But how do you split commits? Command line tools for splitting commits suck because they force you to look at one hunk at a time without getting the context from the rest of the change.
    - stouset 1y ago
      jj uses a TUI for this that lets you navigate the entire set of changes.
      - Zambyte 1y ago
        Not only is the default behavior of `jj split` exceptionally good and not susceptible to the issue they described, but you can easily specify an external tools like the meld gui to offload these operations to as a configuration option.
  - nchmy 1y ago
    Try jjui. It's an amazing TUI
- andrewaylett 1y ago
  I use colocated mode, so Git tools see a detached HEAD but otherwise continue to work. I don't normally use the IDE for creating commits or moving around the repo, but I'll still use it for conflict resolution and for exploring history.
forrestthewoods 1y ago
> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. I’ve tried jj on three occasions and I always get confused by something and just bounce. It hasn’t clicked for me. I’ve only tried it solo hobby projects. For which git is perfectly tolerable. I have many many many complaints about git. But jj doesn’t move the needle for me. Reading this post I am extremely annoyed. Almost every single section is “but more on that later”. It’s still far more complicated than it needs to be. I also really really really hate the jj log rendering. The colors are a sea of barf. Bolding the leading character that represent uniqueness is stupid and adds noise. The username being second is dumb, I almost never care about that. And the bright neon green (empty)(no description set) is such bad spew. Kinda nit picky, but blech. Jujutsu suffers the same thing Git suffers. Every god damn blog post that tries to explain how simple it is just my eyes gloss over and think “this is too complex for me to care”.
- viraptor 1y ago
  > I also really really really hate the jj log rendering You can fully change/customise it. Sounds like you just don't like the default.
  - forrestthewoods 1y ago
    Some people love to tinker and fine tune their tools to behave exactly like they want. I am not one of those people. I hate it. It does not spark my joy. Most people use the default for most of their tools. It’s why Google pays Apple over $20 billion per year to be the default search engine. Because defaults matter.
    - stouset 1y ago
      FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box. > I’ve only tried it solo hobby projects. If I can surmise a bit, this is probably why it's never felt "worth it". I'm guessing that for a hobby project you don't really care that much about crafting small, easily-digestible PRs or keeping a clean history. `git commit -a` every now and then is good enough, and that's entirely reasonable. For team projects, jj becomes a much bigger deal. I find it invaluable for splitting up a day's worth of work into small, parallel, easily-reviewable changes. While working on one feature I might run across a dozen other things that should be fixed, improved, or otherwise changed. Bundling them into one giant PR is bad practice and causes reviews to take much longer. Carving those up into single-purpose PRs that can be reviewed in seconds and tested independently is super helpful on a project with multiple teammates. But that's not something that really matters or that most people care to take the time do to in personal projects. Hell, it's something a lot of people punt on a lot in git due to the extra burden of doing so.
lawn 1y ago
Eh, not really. I've used it and I like it but I couldn't find a good plugin for Neovim so I reverted back to my old more well-supported workflow.
resonious 1y ago
I used jj for several months, then eventually went back to git. The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now. But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constant use though.
- npinsker 1y ago
  I used to have the same problem (on Windows only, not Mac) but it seems to have been fixed as of a month or two ago.
  - Filligree 1y ago
    There's a noticeable delay when doing operations on Nixpkgs (to the tune of a quarter-second), but that's a huge repository. Everything else is instant.
- raylu 1y ago
  I ran into this at first on a large-ish repo. watchman fixed it: https://jj-vcs.github.io/jj/latest/config/#filesystem-monitor https://jj-vcs.github.io/jj/latest/config/#filesystem-monito...
esperent 1y ago
> there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. This sounds exactly like something a person evangelizing it would say.
- nchmy 1y ago
  The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? What other tools do people do that for? Not many. I see the most similar language and behaviour with regards to uv, which similarly revolutionized/simplified python tooling. Likewise mise, which makes it similarly frictionless to install and manage tooling and their versions across projects and system-wide. The evangelizing for these things comes because these tools start to heal the trauma that came from immense friction. We want others to be similarly liberated. For those who say "I don't feel friction/trauma with git, legacy Python tooling etc", I can only say that you're living in Plato's cave/the matrix/in a cult/with Stockholm syndrome and just don't know what you're missing out on.
  - riwsky 1y ago
    “Trauma” is a bit much.
    - nchmy 1y ago
      Definitely applies more to uv than jj, but jj is still immensely liberating. To the extent that people are willing to evangelize it to no gain of their own.
  - petesergeant 1y ago
    > What other tools do people do that for? Text editors, programming languages, shells, VCSs, nix/guix…
  - Levitz 1y ago
    >The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? To make a point? To prove that "they are right"? People do this constantly, tools, libraries, languages... All the time really.
globular-toast 1y ago
I tried it and didn't switch. The funny thing is I immediately recognised that it was forcing me to use git in basically the same way I use it anyway. I have more than 15 years experience with git at this point. I never had to do the "delete repo and reclone" thing after the first year. In other words, I actually understand git, so I don't really need Jujutsu. I also already use very good tooling for git, namely Magit. IMO Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all. It's quite remarkable. Maybe I should recommend jj to some of my colleagues, though. Trouble is I'm already on the hook for helping them with git, but I don't have the experience with jj.
- stouset 1y ago
  > In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete. I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as I can remember. jj is still leagues better. Things I want to do and know how to do in git are dramatically faster and easier. They require less mental overhead. They’re less error prone. And I get superpowers with workflows that are super useful but wildly impractical in git. This isn’t even really opinion at this point. Any task you can give me in git, I can with almost near certainty give you a shorter and more elegant alternative with jj that is an intuitive and obvious interaction with its core primitives. A month ago our company split off a division. They needed to take a specific repo and sanitize out all of the parts that aren’t relevant to the new company, going back to the beginning of its commit history. You can do this with git. It wouldn’t be fun. I’d have to spend a lot of time reading the filter-branch manpage, and people have written countless wrappers of varying quality that try and make it a bit more ergonomic. It took me like ten minutes to come up with: declare -rA paths=( … ) # for every commit that touched a file # we want to excise for id in "$( jj log \ --revisions '..' \ --no-graph \ --template 'change_id ++ "\n"' \ "${paths[@]}" )"; do # restore those paths’ contents from the # the empty root commit; this happens # entirely in-memory without having to check # out each revision into the working copy to # do file operations so it is FAST jj restore \ --from 'root()' \ --to "${id}" \ "${paths[@]}" done # remove any commits that are now empty # (except for the implicit root commit) jj abandon \ --revisions 'empty() ~ root()' Three dumb, simple commands that I already use every day: list some commits, copy file contents from one commit into another, and remove some commits from the tree. Not only was this more or less obvious to do, but it was exceedingly fast to perform on a pretty highly-trafficked repo due to not having to thrash around in the working directory with checkouts. > Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all. jj is more powerful than git. It’s not simply a dumbed-down alternative. By having a more carefully chosen set of primitives that compose better, you gain a lot of abilities that are technically possible with git but never used in practice due to the complexity. The above is IMO a fantastic example of how and why. And you can still do all the normal git things too.
weinzierl 1y ago
"You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. " Reporting in. Doesn't mean I will not end up with jj eventually, but so far I always went back to git after a while. For me it is the staging area and the workflow it allows. Most people hate it and love jj because it does away with it. That is just not me. I don't see the staging area as a hack that was necessary to overcome some superfluous technical limitations but as a workflow tool. Could I change my ways? Sure. jj just did not provide enough benefit for me so far to do it, but we will see. I am still open to give jj another try some day.
- stouset 1y ago
  The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if you don't already have one jj new --no-edit --insert-before @ # move changes into it; repeat ad nauseam jj squash --interactive Since it's just a commit, all your tools work with it out of the box. And you don't need to stash changes when you jump around between branches.
  - weinzierl 1y ago
    Thanks for the clear and concise summary. It is helpful for some workflows. For me the staging area being a snowflake is the feature. It is a special temporary singleton commit if you will, but I can rely on its temporary and singleton nature. As that it should have a different interface from regular commits.
  - nchmy 1y ago
    Yeah, I regularly have MANY "staging commits" at the same time in jj, in which I just throw ideas in that I don't want to pollute or yet know how to integrate with the other ideas. I use squash, split, interactive split, rebase etc to move lines and changes around etc... When I eventually figure it all out, I can tidy it all up into completely coherent, discrete, sequential commits that make it look like I knew exactly what I was doing from the start, then push to remote. Conversely git staging around stashing was always an absolute, terrifying mystery to me. I could never remember what was stored where, and would consequently end up losing work, repeating work, and, most of all, just making massive commits that make no sense. I was sold on jj from essentially the moment I found it, but I remain routinely amazed at how much more powerful (yet simple!) it is than I realized.
xdfgh1112 1y ago
I tried it and I went back to git. I know how git works though. I don't put much stock into your 'anecdata'
xelxebar 1y ago
It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and git-bug, becomes second class, i.e. no oplog integration and they might mess up your log with internal-use commits and heads.
- steveklabnik 1y ago
  > line ending settings will get ignored, making Windows interop a little less smooth; etc. This one got fixed just a few days ago! https://github.com/jj-vcs/jj/pull/6728 https://github.com/jj-vcs/jj/pull/6728
- stouset 1y ago
  These are all really excellent points, and well worth calling out.
- Ayesh 1y ago
  I use gitattributes quite a lot (lfs, various diff engines, and export-ignore). Thanks for the heads-up, jj looked very interesting but I'm not going to give up gitattrivutes.
  - dilap 1y ago
    They are slowly working on it: https://github.com/jj-vcs/jj/issues/53 https://github.com/jj-vcs/jj/issues/53 (I am interested because I want to try, but need git-lfs, which needs gitattributes.)
- IshKebab 1y ago
  > line ending settings will get ignored Arguably a good thing - git's autocrlf setting causes way more issues than it solves. I highly recommend setting it to "input" (basically bans CRLF).
- 1y ago
sngz 1y ago
I always go back to using mercurial for personal projects. Better than both
- windward 1y ago
  'Doesn't use Mercurial' was top of my requirements list last time I left a job that did use it.
- arunix 1y ago
  Can you say more about how it's better than both?
  - sngz 1y ago
    easy to understand and use for everyone. you no longer need to spend tons of time teaching junior devs how to use git. By default mercurial also doesn't let you change history. There's no staging area or indexing before the commit. The gui and commands make total sense to the layman. Git is definitely more powerful but causes more damage than good and wastes more time in most workplaces who are just looking for some simple version control and branching/merging features.
- WXLCKNO 1y ago
  Not typing hg is the best part of my day
palata 1y ago
> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff. But you will be infinitely more productive: when you start bim, you're already in edit mode, so you don't have to type i! And the auto-complete in Julia is objectively a lot better in bim!". Sure, but typing "i" a few times more is really not a concern for me, and I don't use Julia. But if it's better for you, please enjoy bim!
- stouset 1y ago
  For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. I greatly prefer working with (and being) the kind of developer that puts out a large number of very tiny and easy to review PRs, eve. jj makes doing that a breeze. There are lots of people for whom these things aren't important. I will be slightly judgmental and say I don't really enjoy working with them. They tend to write very large PRs that are difficult and time-consuming to review. And it's a frequent source of frustration for everyone when 95% of the work is uncontroversial but a merge is being held up because of legitimate concerns with an unrelated 5%. This is even worse when there's later work that builds upon it that can't happen until a merge (or that needs to be constantly rebased as the PR is improved). This is not to say if you do this you’re a bad developer. There are plenty of great developers who don’t care about these things and still do great work. This is also not to say you can’t follow my preferred approach with git. I did it with git for a decade and a half.
  - beng-nl 1y ago
pjmlp 1y ago
If I had an option, I would still be using something like Subversion or Mercurial. As it is, I go with whatever our clients require of us, and that isn't jj.
- nchmy 1y ago
  You're misunderstanding. You can use it with any git repo without anyone knowing.
  - pjmlp 1y ago
    Usually I am pretty much against snowflake approaches in project delivery, setup should be the same for everyone, as people change roles across projects routinely.
    - nothrabannosir 1y ago
      The delivery is the repo and its commits. Recommending a setup is one thing, but enforcing particular tools has about the same level of appreciation among any senior dev I know as enforcing a keyboard model.
      - pjmlp 1y ago
        Those senior devs don't work on the kind of industry that I work on, enterprise consulting with high attrition of team members, and possible offshore teams. This kind of industry work needs factory line mindset, there aren't special knobs for someone on the sidelines working on the software rolling carpet, which granted isn't for everyone.
        nchmy 1y ago
        Can you choose your own IDE? if so, you should be able to choose how you manage git locally, such as with jj.
        1y ago
baq 1y ago
my heuristic is: do you know about git rerere? if yes - try jj.
darthrupert 1y ago
You can consider your perfect conversion rate now broken; I tried jujutsu on a personal project and found it to be a hassle without any upsides. I believe your perception is flawed because the people who just try it and throw it away don't tend to talk about it because it's not popular enough to warrant even a twitter comment. This is the first time I got the impulse to share this but only because you claimed a rather silly 100% conversion rate.
- nchmy 1y ago
  Care to elaborate on the hassle and lack of upsides? Have you considered that you simply didn't give it a fair shake or were holding it wrong?
  - stouset 1y ago
    I don’t think this is a good approach toward getting people to switch. It’s unnecessarily combative.
    - nchmy 1y ago
      Even though the parent comment was outrageously combative, you're probably right that it wasn't necessary to reply in a much milder, but similar fashion.
      - darthrupert 1y ago
        Perhaps you just didn't give my comment a fair shake and were reading it wrong. But I don't think parent comment to mine was "outrageously combative", I just thought it was a bit silly to claim a 100% conversion rate.
fedeb95 1y ago
this still doesn't imply it is worth checking out.
tgv 1y ago
> I have seen a 100% conversion rate from everyone who gave it a serious try. Cognitive dissonance is a thing.
pinoy420 1y ago
[dead]
mcepl 1y ago
yes, I haven’t managed for a week, but I tried to Jujutsu and gave up. It is too complicated for no visible gain. Plus, there is no infrastructure supporting it (in the end, you store the stuff in the crippled git repositories). `git commit --amend` and `git rebase --update-refs` together with few scripts (e.g., https://git.sr.ht/~mcepl/git-fixup https://git.sr.ht/~mcepl/git-fixup) does the same, and I am still with true git.
- nchmy 1y ago
  Git infrastructure works just fine with jj... And there's nothing crippled about thr git repos. Try jjui for a great TUI experience on top of jj.
ben0x539 1y ago
I'm sure if I did the proper time investment I would enjoy jj. I've heard basically only good things about it in casual conversation. So far, my experience has been that I tried it, immediately got really annoyed that it automatically adds every untracked file that's not gitignored to the current commit, and was advised that I might want to stay with git if that's a problem. That said, I struggle a bit with learning version control systems (that aren't git, like, I never really wrapped my head around svn or darcs or anything until they invented git). Seems like everybody just wants to write about the cool new commands they can run now instead of conveying how the data model works, or what mental model it wants to encourage. I had the same issue trying to get into pijul a while back, couldn't understand how to conceptualize the current state of a branch if I couldn't point at a commit in a tree and say "that's the branch, right there".
- riwsky 1y ago
  Mental model: “everything is a commit”. Commits are commits. Stashes are commits. The working tree is a commit. The index doesn’t exist, because it’s unnecessary. The data model is technically of revisions, which are stable across operations like rebases (which change the underlying git commit). How to conceptualize a branch: as a bookmark of a specific commit.
  - ben0x539 1y ago
    Yeah, I think that extra layer of revision identity is giving my intuition trouble, like it's obvious it needs to be there but the consequences are still percolating through my head.
deleted 1y ago
[deleted]
homebrewer 1y ago
I used it for several days and went back to git; it doesn't really provide that much for someone already proficient with git, and you need to know the underlying mechanism well for when something goes wrong anyway (just like with any other abstraction).
nchmy 1y ago
There's also subcamps. Those who have tried it and 1) actually gave it a fair shake - and are now evangelize it, and 2) people who simply didn't give it a fair shake due to a) time restraints and b) just not having an open enough mind to genuinely try it out And then those who haven't tried it but 1) have never heard of it, and 2) are unwilling to try it because they are stuck in their ways (I view these people as being in Plato's Cave, or the matrix, or a cult - even though us evangelizers obviously sound like we're in a cult). They're in an even sadder position than those who tried it half-heartedly. All such sorts of people are on display in this thread. I hope us zealots have been able to convince (hopefully via education) at least a few to try it out. And also to try jjui, which is incredible. https://github.com/idursun/jjui https://github.com/idursun/jjui
begueradj 1y ago
> I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. When it's our first time, the tissue damage caused by the training can weight a lot to the point we could not even be able to sit properly in front of the desk during the first couple of weeks.
renox 1y ago
At work we 1) use a git hook to generate Gerrit IDs for new commit. AFAIK, JJ doesn't support these. 2) we also use submodules, which must be handled using git commands. So if I decide to use JJ, I'll have to use a mix of JJ and git..
- stouset 1y ago
  For 1, gerrit and jj have recently collaborated to standardize on a commit footer where stable revision IDs are encoded in the jj style. This landed in a jj release a few months back. I assume it’s live in gerrit now too.
christophilus 1y ago
I used it for a little over a week, and switched back. This was a while ago, but the main reason was my neovim setup and flow never felt as good. Maybe jj has a good neovim plugin and diff mechanism now, though?
__turbobrew__ 1y ago
How fast I can deliver value is almost never gated by my VCS, so why should I try? In total I maybe lose a few minutes a month to VCS impedance mismatch, and I am merging on average ~4-5 PRs a day. For sure git is hard to learn for beginners and there could be an alternative which is easier to pick up (maybe jj) but for those who know how git works internally and are proficient with it I don’t see it being worth the switch.
- sshine 1y ago
  > How fast I can deliver value is almost never gated by my VCS Oh, the number of times I do git commit --fixup ...searches `git log` and pastes`... && \ git rebase -i --autosquash ...that same commit^... I waste several half minutes several times per day in periods! Another time-consuming thing is context-switching from a feature branch with staged/unstaged changes. If you're good with worktrees, you can largely avoid this, but the way I work with worktrees, I instantiate them as subdirectories to my repo's parent, which clutters my directories unless I make space for this as I clone the repository, which I haven't got used to. I deliberately avoid too complicated git workflow aliases because I hate being stuck without them. I am definitely in the camp of "I'd switch to jj the moment I give myself time to try it." In the meantime, running git commands does sometimes take more time than it needs to.
  - dmsnell 1y ago
    You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message. git rebase -i --rebase-merges --keep-base trunk This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvements from jj, except it’s just git. This article from Andrew Lock on stacked branches in git was a great inspiration for me, and where I learned about --update-refs: https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ https://andrewlock.net/working-with-stacked-branches-in-git-...
    - 1y ago
dpc_01234 1y ago
Fwiw. It took me 4 or 5 attempts of various lengths (2 to 10 days) before I actually sticked with it. I've hit unimplemented deal breakers and was generally uncomfortable a lot. Now I like it more than git, but I don't think the difference is large and stacking commits is a bit of a pass time for me. I do it more now because it's easier but I would just do less of it with git and no one would care much.
dilap 1y ago
There is a 3rd group (probably mostly gamedevs) who think it seems like a great idea and really want to try it, but are blocked waiting for git-lfs support. Every time jujutsu pops back up on HN I check to see if they've added it yet. Not yet! But they are slowly getting there: https://github.com/jj-vcs/jj/issues/80 https://github.com/jj-vcs/jj/issues/80
- tex0 1y ago
  Maybe they need perforce support instead :P
- spott 1y ago
  Do you know what this means in practice? Is it that I have to fall back to git for its changes? Or that I just shouldn’t use jj if I’m in a repo with lfs files?
  - dilap 1y ago
    I'm not sure, if you scroll through the bug report there seem to be some people maybe kind of making it work, but I couldn't figure out exactly what they were doing, so decided I'll just keep waiting for the real implementation.
lolstarz 1y ago
I have noticed this trend too. I don't know if I'm simply too smooth-brained for `jj` or what, but I forced myself to use it for a month to give it a fair shake and simply couldn't grok it. I gave up and went back to rawdogging git. So there are at least some of us out there.
yungporko 1y ago
i've never considered testing out any of the new version control systems i see from time to time for the simple reason that i already know git, everybody else already knows git, git already completely handles everything i could conceivably want it to do (and a bunch more stuff that i will never touch), and perhaps biggest of all, i can't tell my manager that i want our whole team to migrate our code into (new thing) which everybody will have to learn for no reason. serious question as somebody who has never even looked into what jujutsu offers - unless you're a solo dev with some free time, what exactly is the selling point here? edit: i didnt realise that its just a layer on top of git so that basically answers my question, fair
qudat 1y ago
> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. I used it for a week and switched back to `git`. Most of its hallmark features are not something I use that often.
rodrigodlu 1y ago
I did that and went "back". Most of the projects I do for money are on Github and Gitlab. I got my hands on things like YT videos explaining, official docs, cheatsheets. About 4 hours exploring, trying to use with some side projects. I did the same decades ago from CVS/SVN to git (even tried Hg). At that time it was obvious the "revolution" + "evolution" effect. Also git provided some transition tools that were easier to use from my pov. Now it's just "evolution". I see the added power to work with different "branches" simultaneously, move commits in different order in a way that is easier to have some better management logic, etc. This is basically compelling if you work on different facets on big monorepos. But I want to work on one thing a time nowadays, do something reliable, instead several features simultaneously, even with AI assistance, so the gains are not that huge, yet. Like you I ended up using git commands again naturally. Stopping using svn commands eons ago felt amazing.
paradox460 1y ago
I tried it a year or two ago and went back to git. I didn't dislike JJ, it just didn't cover all the things I needed to do my usual workflow at the time, and being the only dev on my team using it was a bit tricky I've been meaning to give it another shot, and probably will after this article

0x457 1y ago

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

Valodim 1y ago
There were (are?) people who say the same thing about svn
- 0x457 1y ago
  Sure, but in this case, git being distributed is what sold it for me. I've switched off svn as soon as I've learned of git.
globular-toast 1y ago
I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting. I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.
- tcoff91 1y ago
  It’s really nice to use the —-first-parent flag with bisect.
  - globular-toast 1y ago
    Yeah this is good if you, for some reason, rebase then merge without fast forwarding. I never understood doing this. If I'm going to be ignoring those commits when bisecting then they are useless commits just using up disk space IMO. Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.
    - 1718627440 1y ago
      For me a merge is about grouping commits, when you have just a list of commits, the list can be very long. That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.
      - globular-toast 1y ago
        The whole point of bisect is to make it quicker to find a point in a potentially long list of commits. Finding the feature first then bisecting within the branch is only going to make it slower, and requires you to manually restart the bisect. I use the commit message to add ticket numbers to things to group commits.
        1718627440 1y ago
        The commits surrounding them (logically) are probably also relevant, which you will find easier when you have grouped commits by features. I prefer to have everything in a single source of truth (git), so everything is in commits. Your tickets are my merge commits.
ykonstant 1y ago
Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.
- falconertc 1y ago
  Bisect is a very cool feature that I used once over 5 years ago. The collection of git tools that I use often is very small. I've found that the more experienced I got with git, the less I found myself in scenarios where I needed git's more complex tools.
  - theLiminator 1y ago
    Hmm, bisect is definitely not one of those.
- 1718627440 1y ago
  Yes not using bisect, seams like you do all the work to record information, but then never use that information to save work?
  - 0x457 1y ago
    May I use how often and why you use bisect? I don't remember the last time I needed bisect. Well, I also don't work in linux kernel sized repos, so there is that.
    - 1718627440 1y ago
      > May I use Was that 'may I ask'? Not that often, but not seldom. Its useful if you have a bug, that isn't obvious where it comes from, but easily testable. Then you just write a test and let git figure out where it comes from. The test doesn't need to be automatable. I also used it for firmware that needs to be flashed and the bug effected in an LED blinking incorrectly. I still saved a lot of time.
      - 1y ago
anticodon 1y ago
I used bisect once in my life but it was extremely helpful. Without it I'd spend weeks trying to find regression. With bisect I found and fixed it in under 1 hour. It's a command that is needed rarely but there's no replacement for it in some situations.
- pclowes 1y ago
  I am confused by this, isn't Bisect just some git ergonomics with respect to flagging a checked out commit as a success failure and then checking out the next midway commit depending of if it was a success/failure to enable classic binary search? It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I like the ergonomics but only use it once every couple years.
  - anticodon 1y ago
    Agree, probably could be done in any other VCS as well, including CVS. But only possible if you actually use VCS and use it properly.

bjackman 1y ago

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me. Even though my main work involves quite a lot of annoying rebases which is where JJ really seems to shine. I dunno I guess it's just that a) I've really mastered git and have a deeply-rooted workflow in it and b) despite my project involving annoying rebases, version control still isn't very high on the list of problems I have. So yeah I'm basically bullish on JJ as a technology but I think movement from Git is inevitably gonna be slow and steady.

stouset 1y ago
I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.
- bjackman 1y ago
  Yeah I guess it confirms your point in a way too. There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all. So yeah this is still basically a recommendation for people to try JJ!
sethammons 1y ago
Curious, I was under the impression that Google was all a monorepo, but your phrasing suggests that there are others. As my company is pushing for a monorepo, I'd love to know what causes someone at big G to not be in the monorepo. Thanks for any insights you can help me with!

nephalegm 1y ago

I started doing jujitsu a few months ago. The title of the article and this top comment had me bewildered until I remembered what jujitsu was in this space LOL

esafak 1y ago

Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.

Disposal8433 1y ago
I've always hated the git CLI, and that's why I used Jetbrains tools or Sublime Merge. Now that I switched to jj (colocated with a get repo, very useful), I went back to using the CLI again for jj and I don't miss the graphical tools.
- exclipy 1y ago
  But how do you split commits? Command line tools for splitting commits suck because they force you to look at one hunk at a time without getting the context from the rest of the change.
  - stouset 1y ago
    jj uses a TUI for this that lets you navigate the entire set of changes.
    - Zambyte 1y ago
      Not only is the default behavior of `jj split` exceptionally good and not susceptible to the issue they described, but you can easily specify an external tools like the meld gui to offload these operations to as a configuration option.
- nchmy 1y ago
  Try jjui. It's an amazing TUI
andrewaylett 1y ago
I use colocated mode, so Git tools see a detached HEAD but otherwise continue to work. I don't normally use the IDE for creating commits or moving around the repo, but I'll still use it for conflict resolution and for exploring history.

forrestthewoods 1y ago

> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. I’ve tried jj on three occasions and I always get confused by something and just bounce. It hasn’t clicked for me. I’ve only tried it solo hobby projects. For which git is perfectly tolerable. I have many many many complaints about git. But jj doesn’t move the needle for me. Reading this post I am extremely annoyed. Almost every single section is “but more on that later”. It’s still far more complicated than it needs to be. I also really really really hate the jj log rendering. The colors are a sea of barf. Bolding the leading character that represent uniqueness is stupid and adds noise. The username being second is dumb, I almost never care about that. And the bright neon green (empty)(no description set) is such bad spew. Kinda nit picky, but blech. Jujutsu suffers the same thing Git suffers. Every god damn blog post that tries to explain how simple it is just my eyes gloss over and think “this is too complex for me to care”.

viraptor 1y ago
> I also really really really hate the jj log rendering You can fully change/customise it. Sounds like you just don't like the default.
- forrestthewoods 1y ago
  Some people love to tinker and fine tune their tools to behave exactly like they want. I am not one of those people. I hate it. It does not spark my joy. Most people use the default for most of their tools. It’s why Google pays Apple over $20 billion per year to be the default search engine. Because defaults matter.
  - stouset 1y ago
    FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box. > I’ve only tried it solo hobby projects. If I can surmise a bit, this is probably why it's never felt "worth it". I'm guessing that for a hobby project you don't really care that much about crafting small, easily-digestible PRs or keeping a clean history. `git commit -a` every now and then is good enough, and that's entirely reasonable. For team projects, jj becomes a much bigger deal. I find it invaluable for splitting up a day's worth of work into small, parallel, easily-reviewable changes. While working on one feature I might run across a dozen other things that should be fixed, improved, or otherwise changed. Bundling them into one giant PR is bad practice and causes reviews to take much longer. Carving those up into single-purpose PRs that can be reviewed in seconds and tested independently is super helpful on a project with multiple teammates. But that's not something that really matters or that most people care to take the time do to in personal projects. Hell, it's something a lot of people punt on a lot in git due to the extra burden of doing so.

lawn 1y ago

Eh, not really. I've used it and I like it but I couldn't find a good plugin for Neovim so I reverted back to my old more well-supported workflow.

resonious 1y ago

I used jj for several months, then eventually went back to git. The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now. But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constant use though.

npinsker 1y ago
I used to have the same problem (on Windows only, not Mac) but it seems to have been fixed as of a month or two ago.
- Filligree 1y ago
  There's a noticeable delay when doing operations on Nixpkgs (to the tune of a quarter-second), but that's a huge repository. Everything else is instant.
raylu 1y ago
I ran into this at first on a large-ish repo. watchman fixed it: https://jj-vcs.github.io/jj/latest/config/#filesystem-monitor https://jj-vcs.github.io/jj/latest/config/#filesystem-monito...

esperent 1y ago

> there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. This sounds exactly like something a person evangelizing it would say.

nchmy 1y ago
The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? What other tools do people do that for? Not many. I see the most similar language and behaviour with regards to uv, which similarly revolutionized/simplified python tooling. Likewise mise, which makes it similarly frictionless to install and manage tooling and their versions across projects and system-wide. The evangelizing for these things comes because these tools start to heal the trauma that came from immense friction. We want others to be similarly liberated. For those who say "I don't feel friction/trauma with git, legacy Python tooling etc", I can only say that you're living in Plato's cave/the matrix/in a cult/with Stockholm syndrome and just don't know what you're missing out on.
- riwsky 1y ago
  “Trauma” is a bit much.
  - nchmy 1y ago
    Definitely applies more to uv than jj, but jj is still immensely liberating. To the extent that people are willing to evangelize it to no gain of their own.
- petesergeant 1y ago
  > What other tools do people do that for? Text editors, programming languages, shells, VCSs, nix/guix…
- Levitz 1y ago
  >The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? To make a point? To prove that "they are right"? People do this constantly, tools, libraries, languages... All the time really.

globular-toast 1y ago

I tried it and didn't switch. The funny thing is I immediately recognised that it was forcing me to use git in basically the same way I use it anyway. I have more than 15 years experience with git at this point. I never had to do the "delete repo and reclone" thing after the first year. In other words, I actually understand git, so I don't really need Jujutsu. I also already use very good tooling for git, namely Magit. IMO Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all. It's quite remarkable. Maybe I should recommend jj to some of my colleagues, though. Trouble is I'm already on the hook for helping them with git, but I don't have the experience with jj.

stouset 1y ago
> In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete. I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as I can remember. jj is still leagues better. Things I want to do and know how to do in git are dramatically faster and easier. They require less mental overhead. They’re less error prone. And I get superpowers with workflows that are super useful but wildly impractical in git. This isn’t even really opinion at this point. Any task you can give me in git, I can with almost near certainty give you a shorter and more elegant alternative with jj that is an intuitive and obvious interaction with its core primitives. A month ago our company split off a division. They needed to take a specific repo and sanitize out all of the parts that aren’t relevant to the new company, going back to the beginning of its commit history. You can do this with git. It wouldn’t be fun. I’d have to spend a lot of time reading the filter-branch manpage, and people have written countless wrappers of varying quality that try and make it a bit more ergonomic. It took me like ten minutes to come up with: declare -rA paths=( … ) # for every commit that touched a file # we want to excise for id in "$( jj log \ --revisions '..' \ --no-graph \ --template 'change_id ++ "\n"' \ "${paths[@]}" )"; do # restore those paths’ contents from the # the empty root commit; this happens # entirely in-memory without having to check # out each revision into the working copy to # do file operations so it is FAST jj restore \ --from 'root()' \ --to "${id}" \ "${paths[@]}" done # remove any commits that are now empty # (except for the implicit root commit) jj abandon \ --revisions 'empty() ~ root()' Three dumb, simple commands that I already use every day: list some commits, copy file contents from one commit into another, and remove some commits from the tree. Not only was this more or less obvious to do, but it was exceedingly fast to perform on a pretty highly-trafficked repo due to not having to thrash around in the working directory with checkouts. > Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all. jj is more powerful than git. It’s not simply a dumbed-down alternative. By having a more carefully chosen set of primitives that compose better, you gain a lot of abilities that are technically possible with git but never used in practice due to the complexity. The above is IMO a fantastic example of how and why. And you can still do all the normal git things too.

weinzierl 1y ago

"You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. " Reporting in. Doesn't mean I will not end up with jj eventually, but so far I always went back to git after a while. For me it is the staging area and the workflow it allows. Most people hate it and love jj because it does away with it. That is just not me. I don't see the staging area as a hack that was necessary to overcome some superfluous technical limitations but as a workflow tool. Could I change my ways? Sure. jj just did not provide enough benefit for me so far to do it, but we will see. I am still open to give jj another try some day.

stouset 1y ago
The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if you don't already have one jj new --no-edit --insert-before @ # move changes into it; repeat ad nauseam jj squash --interactive Since it's just a commit, all your tools work with it out of the box. And you don't need to stash changes when you jump around between branches.
- weinzierl 1y ago
  Thanks for the clear and concise summary. It is helpful for some workflows. For me the staging area being a snowflake is the feature. It is a special temporary singleton commit if you will, but I can rely on its temporary and singleton nature. As that it should have a different interface from regular commits.
- nchmy 1y ago
  Yeah, I regularly have MANY "staging commits" at the same time in jj, in which I just throw ideas in that I don't want to pollute or yet know how to integrate with the other ideas. I use squash, split, interactive split, rebase etc to move lines and changes around etc... When I eventually figure it all out, I can tidy it all up into completely coherent, discrete, sequential commits that make it look like I knew exactly what I was doing from the start, then push to remote. Conversely git staging around stashing was always an absolute, terrifying mystery to me. I could never remember what was stored where, and would consequently end up losing work, repeating work, and, most of all, just making massive commits that make no sense. I was sold on jj from essentially the moment I found it, but I remain routinely amazed at how much more powerful (yet simple!) it is than I realized.

xdfgh1112 1y ago

I tried it and I went back to git. I know how git works though. I don't put much stock into your 'anecdata'

xelxebar 1y ago

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and git-bug, becomes second class, i.e. no oplog integration and they might mess up your log with internal-use commits and heads.

steveklabnik 1y ago
> line ending settings will get ignored, making Windows interop a little less smooth; etc. This one got fixed just a few days ago! https://github.com/jj-vcs/jj/pull/6728 https://github.com/jj-vcs/jj/pull/6728
stouset 1y ago
These are all really excellent points, and well worth calling out.
Ayesh 1y ago
I use gitattributes quite a lot (lfs, various diff engines, and export-ignore). Thanks for the heads-up, jj looked very interesting but I'm not going to give up gitattrivutes.
- dilap 1y ago
  They are slowly working on it: https://github.com/jj-vcs/jj/issues/53 https://github.com/jj-vcs/jj/issues/53 (I am interested because I want to try, but need git-lfs, which needs gitattributes.)
IshKebab 1y ago
> line ending settings will get ignored Arguably a good thing - git's autocrlf setting causes way more issues than it solves. I highly recommend setting it to "input" (basically bans CRLF).
1y ago

sngz 1y ago

I always go back to using mercurial for personal projects. Better than both

windward 1y ago
'Doesn't use Mercurial' was top of my requirements list last time I left a job that did use it.
arunix 1y ago
Can you say more about how it's better than both?
- sngz 1y ago
  easy to understand and use for everyone. you no longer need to spend tons of time teaching junior devs how to use git. By default mercurial also doesn't let you change history. There's no staging area or indexing before the commit. The gui and commands make total sense to the layman. Git is definitely more powerful but causes more damage than good and wastes more time in most workplaces who are just looking for some simple version control and branching/merging features.
WXLCKNO 1y ago
Not typing hg is the best part of my day

palata 1y ago

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff. But you will be infinitely more productive: when you start bim, you're already in edit mode, so you don't have to type i! And the auto-complete in Julia is objectively a lot better in bim!". Sure, but typing "i" a few times more is really not a concern for me, and I don't use Julia. But if it's better for you, please enjoy bim!

stouset 1y ago
For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. I greatly prefer working with (and being) the kind of developer that puts out a large number of very tiny and easy to review PRs, eve. jj makes doing that a breeze. There are lots of people for whom these things aren't important. I will be slightly judgmental and say I don't really enjoy working with them. They tend to write very large PRs that are difficult and time-consuming to review. And it's a frequent source of frustration for everyone when 95% of the work is uncontroversial but a merge is being held up because of legitimate concerns with an unrelated 5%. This is even worse when there's later work that builds upon it that can't happen until a merge (or that needs to be constantly rebased as the PR is improved). This is not to say if you do this you’re a bad developer. There are plenty of great developers who don’t care about these things and still do great work. This is also not to say you can’t follow my preferred approach with git. I did it with git for a decade and a half.
- beng-nl 1y ago

pjmlp 1y ago

If I had an option, I would still be using something like Subversion or Mercurial. As it is, I go with whatever our clients require of us, and that isn't jj.

nchmy 1y ago
You're misunderstanding. You can use it with any git repo without anyone knowing.
- pjmlp 1y ago
  Usually I am pretty much against snowflake approaches in project delivery, setup should be the same for everyone, as people change roles across projects routinely.
  - nothrabannosir 1y ago
    The delivery is the repo and its commits. Recommending a setup is one thing, but enforcing particular tools has about the same level of appreciation among any senior dev I know as enforcing a keyboard model.
    - pjmlp 1y ago
      Those senior devs don't work on the kind of industry that I work on, enterprise consulting with high attrition of team members, and possible offshore teams. This kind of industry work needs factory line mindset, there aren't special knobs for someone on the sidelines working on the software rolling carpet, which granted isn't for everyone.
      - nchmy 1y ago
        Can you choose your own IDE? if so, you should be able to choose how you manage git locally, such as with jj.
        1y ago

baq 1y ago

my heuristic is: do you know about git rerere? if yes - try jj.

darthrupert 1y ago

You can consider your perfect conversion rate now broken; I tried jujutsu on a personal project and found it to be a hassle without any upsides. I believe your perception is flawed because the people who just try it and throw it away don't tend to talk about it because it's not popular enough to warrant even a twitter comment. This is the first time I got the impulse to share this but only because you claimed a rather silly 100% conversion rate.

nchmy 1y ago
Care to elaborate on the hassle and lack of upsides? Have you considered that you simply didn't give it a fair shake or were holding it wrong?
- stouset 1y ago
  I don’t think this is a good approach toward getting people to switch. It’s unnecessarily combative.
  - nchmy 1y ago
    Even though the parent comment was outrageously combative, you're probably right that it wasn't necessary to reply in a much milder, but similar fashion.
    - darthrupert 1y ago
      Perhaps you just didn't give my comment a fair shake and were reading it wrong. But I don't think parent comment to mine was "outrageously combative", I just thought it was a bit silly to claim a 100% conversion rate.

fedeb95 1y ago

this still doesn't imply it is worth checking out.

tgv 1y ago

> I have seen a 100% conversion rate from everyone who gave it a serious try. Cognitive dissonance is a thing.

pinoy420 1y ago

[dead]

mcepl 1y ago

yes, I haven’t managed for a week, but I tried to Jujutsu and gave up. It is too complicated for no visible gain. Plus, there is no infrastructure supporting it (in the end, you store the stuff in the crippled git repositories). `git commit --amend` and `git rebase --update-refs` together with few scripts (e.g., https://git.sr.ht/~mcepl/git-fixup https://git.sr.ht/~mcepl/git-fixup) does the same, and I am still with true git.

nchmy 1y ago
Git infrastructure works just fine with jj... And there's nothing crippled about thr git repos. Try jjui for a great TUI experience on top of jj.

ben0x539 1y ago

I'm sure if I did the proper time investment I would enjoy jj. I've heard basically only good things about it in casual conversation. So far, my experience has been that I tried it, immediately got really annoyed that it automatically adds every untracked file that's not gitignored to the current commit, and was advised that I might want to stay with git if that's a problem. That said, I struggle a bit with learning version control systems (that aren't git, like, I never really wrapped my head around svn or darcs or anything until they invented git). Seems like everybody just wants to write about the cool new commands they can run now instead of conveying how the data model works, or what mental model it wants to encourage. I had the same issue trying to get into pijul a while back, couldn't understand how to conceptualize the current state of a branch if I couldn't point at a commit in a tree and say "that's the branch, right there".

riwsky 1y ago
Mental model: “everything is a commit”. Commits are commits. Stashes are commits. The working tree is a commit. The index doesn’t exist, because it’s unnecessary. The data model is technically of revisions, which are stable across operations like rebases (which change the underlying git commit). How to conceptualize a branch: as a bookmark of a specific commit.
- ben0x539 1y ago
  Yeah, I think that extra layer of revision identity is giving my intuition trouble, like it's obvious it needs to be there but the consequences are still percolating through my head.

deleted 1y ago

[deleted]

homebrewer 1y ago

I used it for several days and went back to git; it doesn't really provide that much for someone already proficient with git, and you need to know the underlying mechanism well for when something goes wrong anyway (just like with any other abstraction).

nchmy 1y ago

There's also subcamps. Those who have tried it and 1) actually gave it a fair shake - and are now evangelize it, and 2) people who simply didn't give it a fair shake due to a) time restraints and b) just not having an open enough mind to genuinely try it out And then those who haven't tried it but 1) have never heard of it, and 2) are unwilling to try it because they are stuck in their ways (I view these people as being in Plato's Cave, or the matrix, or a cult - even though us evangelizers obviously sound like we're in a cult). They're in an even sadder position than those who tried it half-heartedly. All such sorts of people are on display in this thread. I hope us zealots have been able to convince (hopefully via education) at least a few to try it out. And also to try jjui, which is incredible. https://github.com/idursun/jjui https://github.com/idursun/jjui

begueradj 1y ago

> I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. When it's our first time, the tissue damage caused by the training can weight a lot to the point we could not even be able to sit properly in front of the desk during the first couple of weeks.

renox 1y ago

At work we 1) use a git hook to generate Gerrit IDs for new commit. AFAIK, JJ doesn't support these. 2) we also use submodules, which must be handled using git commands. So if I decide to use JJ, I'll have to use a mix of JJ and git..

stouset 1y ago
For 1, gerrit and jj have recently collaborated to standardize on a commit footer where stable revision IDs are encoded in the jj style. This landed in a jj release a few months back. I assume it’s live in gerrit now too.

christophilus 1y ago

I used it for a little over a week, and switched back. This was a while ago, but the main reason was my neovim setup and flow never felt as good. Maybe jj has a good neovim plugin and diff mechanism now, though?

__turbobrew__ 1y ago

How fast I can deliver value is almost never gated by my VCS, so why should I try? In total I maybe lose a few minutes a month to VCS impedance mismatch, and I am merging on average ~4-5 PRs a day. For sure git is hard to learn for beginners and there could be an alternative which is easier to pick up (maybe jj) but for those who know how git works internally and are proficient with it I don’t see it being worth the switch.

sshine 1y ago
> How fast I can deliver value is almost never gated by my VCS Oh, the number of times I do git commit --fixup ...searches `git log` and pastes`... && \ git rebase -i --autosquash ...that same commit^... I waste several half minutes several times per day in periods! Another time-consuming thing is context-switching from a feature branch with staged/unstaged changes. If you're good with worktrees, you can largely avoid this, but the way I work with worktrees, I instantiate them as subdirectories to my repo's parent, which clutters my directories unless I make space for this as I clone the repository, which I haven't got used to. I deliberately avoid too complicated git workflow aliases because I hate being stuck without them. I am definitely in the camp of "I'd switch to jj the moment I give myself time to try it." In the meantime, running git commands does sometimes take more time than it needs to.
- dmsnell 1y ago
  You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message. git rebase -i --rebase-merges --keep-base trunk This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvements from jj, except it’s just git. This article from Andrew Lock on stacked branches in git was a great inspiration for me, and where I learned about --update-refs: https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ https://andrewlock.net/working-with-stacked-branches-in-git-...
  - 1y ago

dpc_01234 1y ago

Fwiw. It took me 4 or 5 attempts of various lengths (2 to 10 days) before I actually sticked with it. I've hit unimplemented deal breakers and was generally uncomfortable a lot. Now I like it more than git, but I don't think the difference is large and stacking commits is a bit of a pass time for me. I do it more now because it's easier but I would just do less of it with git and no one would care much.

dilap 1y ago

There is a 3rd group (probably mostly gamedevs) who think it seems like a great idea and really want to try it, but are blocked waiting for git-lfs support. Every time jujutsu pops back up on HN I check to see if they've added it yet. Not yet! But they are slowly getting there: https://github.com/jj-vcs/jj/issues/80 https://github.com/jj-vcs/jj/issues/80

tex0 1y ago
Maybe they need perforce support instead :P
spott 1y ago
Do you know what this means in practice? Is it that I have to fall back to git for its changes? Or that I just shouldn’t use jj if I’m in a repo with lfs files?
- dilap 1y ago
  I'm not sure, if you scroll through the bug report there seem to be some people maybe kind of making it work, but I couldn't figure out exactly what they were doing, so decided I'll just keep waiting for the real implementation.

lolstarz 1y ago

I have noticed this trend too. I don't know if I'm simply too smooth-brained for `jj` or what, but I forced myself to use it for a month to give it a fair shake and simply couldn't grok it. I gave up and went back to rawdogging git. So there are at least some of us out there.

yungporko 1y ago

i've never considered testing out any of the new version control systems i see from time to time for the simple reason that i already know git, everybody else already knows git, git already completely handles everything i could conceivably want it to do (and a bunch more stuff that i will never touch), and perhaps biggest of all, i can't tell my manager that i want our whole team to migrate our code into (new thing) which everybody will have to learn for no reason. serious question as somebody who has never even looked into what jujutsu offers - unless you're a solo dev with some free time, what exactly is the selling point here? edit: i didnt realise that its just a layer on top of git so that basically answers my question, fair

qudat 1y ago

> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. I used it for a week and switched back to `git`. Most of its hallmark features are not something I use that often.

rodrigodlu 1y ago

I did that and went "back". Most of the projects I do for money are on Github and Gitlab. I got my hands on things like YT videos explaining, official docs, cheatsheets. About 4 hours exploring, trying to use with some side projects. I did the same decades ago from CVS/SVN to git (even tried Hg). At that time it was obvious the "revolution" + "evolution" effect. Also git provided some transition tools that were easier to use from my pov. Now it's just "evolution". I see the added power to work with different "branches" simultaneously, move commits in different order in a way that is easier to have some better management logic, etc. This is basically compelling if you work on different facets on big monorepos. But I want to work on one thing a time nowadays, do something reliable, instead several features simultaneously, even with AI assistance, so the gains are not that huge, yet. Like you I ended up using git commands again naturally. Stopping using svn commands eons ago felt amazing.

paradox460 1y ago

I tried it a year or two ago and went back to git. I didn't dislike JJ, it just didn't cover all the things I needed to do my usual workflow at the time, and being the only dev on my team using it was a bit tricky I've been meaning to give it another shot, and probably will after this article