10 ms·

Steve's Jujutsu Tutorial

158 points by 80x86 2y ago

phildenhoff 2y ago
Steve, I see you’re in this thread. I was using jj for a while before reading your tutorial and yet still found it quite insightful and helpful. Thanks for your contribution!
- steveklabnik 2y ago
  You’re welcome!
deleted 2y ago
[deleted]
drudru 2y ago
Steve wrote this in a very approachable style. It is the first time I really understood what 'jj' is about. I'm actually kind of excited to start using this tool with my git repos.
- steveklabnik 2y ago
  Thanks so much! Just want to point out that this hasn’t been updated in a minute, and in particular, you’ll get some messages about branches being bookmarks now: https://github.com/steveklabnik/jujutsu-tutorial/pull/34 https://github.com/steveklabnik/jujutsu-tutorial/pull/34 I have started on a second iteration of the tutorial in private, and am gonna see if I can get it in shape this weekend. Happy to answer questions about jj!
  - drudru 2y ago
    Thank you Steve! Really enjoying this tutorial. No questions so far.
  - emmelaich 2y ago
    Does "in a minute" mean "not for a long time"? Because that's how my kids use that phrase. English is so great and so confusing!
    - stackghost 2y ago
      It means both "in a long time" and "in a short time", depending on context and intonation.
      - steveklabnik 2y ago
        Yep, isn’t language grand?
  - nchmy 2y ago
    I've been meaning to figure out JJ for a few months now. Part of why I havent was that your tutorial is a bit out of date. I can't wait for a revamp!
    - steveklabnik 2y ago
      Well hopefully I can fix that!
- miguelxpn 2y ago
  No surprises there. Steve has always been a great writer.
nixosbestos 2y ago
One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.
- emmanueloga_ 2y ago
  Helix, the editor? How would you pitch it? Zellij looks powerful but also a bit too complex, following the "kitchen sink" school of design :-). No biggie but its name is too close to IntelliJ imho. What kind of workflow do you use with it? I used tmux a bit back in the day, but these days I feel like good old tabs and app windows cover my needs. When I want to multiplex processes in a single window, I reach for Overmind. [1] -- 1: https://github.com/DarthSim/overmind https://github.com/DarthSim/overmind
  - Lyngbakr 2y ago
    > Helix, the editor? How would you pitch it? Not the OP, but Helix is a minimal fuss modal editor with sensible defaults. My config is maybe five lines? I say "maybe" because I haven't looked at it I first wrote it. And I think I'd probably be just fine with no config.
    - imjonse 2y ago
      Sensible defaults but also out of the box features you only get in vim by finding and configuring external plugins (fuzzy file picker, LSP integration, multi-cursor editing, inline keymapping help). Cons: no session save, good Helix keybindings not available in other tools so confusing to switch between vim/hx mental models when in colab/vscode, no AI-assistants since no plugin system yet.
  - stavros 2y ago
    I don't know what you find complex about Zellij, as I haven't used it extensively, but the few times I've used it, the UI was eminently self-describing, I managed to do everything I've needed to do within a minute of first launching it. Is there more advanced stuff that's more complex that I just haven't seen?
38 2y ago
Jujutsu is terrible in my opinion. people hate the index, but I think they just dont get it. to me a commit is something that is ready to push, and the index is for stuff that is done but not ready to push. just because I wrote one line that I am happy with, doesn't mean I am ready to commit and push that. I prefer to add stuff thats done, then when enough is done I can commit and push. if you remove the index it makes it too easy to push half done stuff
- steveklabnik 2y ago
  I like jj because I like git's index so much. JJ lets me do what git's index does, but in a much more powerful way. What you do is, you treat @ like the index, and you work on @-. This is the "squash workflow" https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
  - 38 2y ago
    [flagged]
    - steveklabnik 2y ago
      https://steveklabnik.github.io/jujutsu-tutorial/hello-world/viewing-contents.html https://steveklabnik.github.io/jujutsu-tutorial/hello-world/... > The very first character at the top left is an @. @ is a special name for "whichever commit the working copy reflects." At first I kind of thought about it like HEAD in git, but that's not correct: HEAD is the most recent commit, but @ represents the working copy, which may be "dirty" from git's point of view. This is our first glimpse into the power of the index-less workflow, though we'll explore that fully in the next chapter. For this moment, just realize that we have one less concept, but haven't actually lost any of its power.
      - 38 2y ago
        OK but again thats awful, because @ IS A COMMIT, so you are only a "git push" away from accidentally pushing arbitrary garbage instead of proper changes
chaostheory 2y ago
I get that naming is one of the hardest problems in computer science, but naming software after a martial art is just lazy and will lead to problems with things like searches
- red_admiral 2y ago
  Like naming your language after a common two-letter verb. At least we can search for 'golang'.
- riwsky 2y ago
  If it helps, they actually named it after their desired CLI abbreviation: > The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
  - gcarvalho 2y ago
    And the martial art is jiu-jitsu, not jujutsu. Similar sounding but definitely not “named after”.
    - yencabulator 2y ago
      No it's not, but so far the Brazilians are still sticking with the incorrect ~1908 way of writing it. Standard Japanese pronunciation for "jutsu" does not contain an i, and it's also judo not "jiu-do" that the old system would have called for. https://en.wikipedia.org/wiki/Jujutsu#Etymology https://en.wikipedia.org/wiki/Jujutsu#Etymology
- stavros 2y ago
  I guess it's lucky they misspelled it, so there's no conflict.
  - martinvonz 2y ago
    I would have spelled it "jiu-jitsu" if I had not looked up the spelling first and found that Wikipedia decided to spell it "jujutsu" (https://en.wikipedia.org/wiki/Jujutsu https://en.wikipedia.org/wiki/Jujutsu). Maybe I trusted Wikipedia too much; I have never practiced jujutsu/jiu-jitsu myself.
aos 2y ago
I’ve started to use jj much more often (and actually used this tutorial to get me started!). I do wish its interaction with Nix flakes is less annoying though, but that’s not the fault jj.
- spott 2y ago
  How is it annoying?
cyanf 2y ago
thank you steve, i’ve been excited for this!
- steveklabnik 2y ago
  You’re welcome!
itohihiyt 2y ago
Came here for a martial arts tutorial, which I thought was a bit weird to see front page on HN, and now I see an alternative to git. I don't particularly like git and for personal projects use fossil instead. Without going through the whole tutorial, and doing a lot more reading, why should I consider using this over fossil?
- kettleballroll 2y ago
  Same. I miss the old times when people tried naming their projects sensibly. I mean, we're constantly telling ourselves how variable and function names should speak for themselves, but then we name our projects using random, completely non-descript names. It's a annoying.
  - chronial 2y ago
    Which old times are you referring to / what are "sensible" names? I thought about it and I don't know what a better name would be. Off the top of my Head, I know Perforce, BitWarden, Subversion, fossil and git. And then the abbreviations CVS, RCS and SVN. Do any of these qualify as a descriptive name?
    - itohihiyt 2y ago
      As a British national I like to think git is a very descriptive name, because git is a git to use and understand.
      - batch12 2y ago
        For a US southerner it works too. We can use the tool to 'git' our code.
    - phrenq 2y ago
      At one point in my career, I used Microsoft SourceSafe, which is a pretty descriptive name. Seems like the exception here, though.
    - 2y ago
ZoomZoomZoom 2y ago
Would be great if it was Pijul that got Steve's attention. Sometimes it's all you need to achieve a lot.
- cinntaile 2y ago
  No updates since March 2024?
- steveklabnik 2y ago
  I’ll just be honest with you: Pijul never really caught my interest, but I always felt pretty neutral about it until I started noticing the project authors acting very snide and aggressive on here. That is not something I want to be around these days, and so I doubt I’ll ever try Pijul.
  - ZoomZoomZoom 2y ago
    It's a little surprising to hear, from what I've seen here there's not much besides the usual whiff of academical loftiness, but nothing that I'd qualify as aggression. What caught my interest: * Separate operations and data * Partial repos = no big repo issues, no need for shallow clones and such * Proper and easy merging with no shuffled lines * Patch-based model is much more intuitive (e.g. rebase and merge are the same operation) * Conflict resolutions are stored and can be reapplied!
lawn 2y ago
I really like Jujutsu but I went back to Git because there wasn't a Neovim plugin with features comparable to Neogit or Fugitive. I even started writing one but that was a pretty big project and I lost the motivation for it.
- steveklabnik 2y ago
  I’ve heard people say similar things about magit. Tooling matters a lot, for sure.
red_admiral 2y ago
I expected actual Jujutsu :) I recommend looking up Bartitsu (that Conan Doyle spelled Baritsu), a short-lived but very interesting martial art.
klauserc 2y ago
Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")
- conaclos 2y ago
  > The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?
  - abhinavk 2y ago
    No from what I see. It does that whenever you run any jj command. I haven't checked the source.
    - sheremetyev 2y ago
      by default snapshotting happens on each jj command additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman https://martinvonz.github.io/jj/latest/config/#watchman
  - aseipp 2y ago
    It's a bit of a magic trick. A "snapshot" is taken any time a command is run, and it happens implicitly before any actual algorithms or code for a given command is run (massively simplifying the internal design), so for all intents and purposes it's "automatic" from the user interface e.g. even checking repo status or otherwise small operations will cause a snapshot. But you can integrate with https://github.com/facebook/watchman/ https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.
videlov 2y ago
Martin (the jj creator) recently gave a talk at the Git Merge 2024 conference: https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G
leighleighleigh 2y ago
It's my first time encountering your writing Steve, loved it! Time to give JJ another crack...
- steveklabnik 2y ago
  Glad to hear it!
swiftcoder 2y ago
> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.
- arccy 2y ago
  because it's a name that describes the technical implementation, not the end user experience
  - swiftcoder 2y ago
    Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.
    - steveklabnik 2y ago
      This is a major issue for sure. Like a big enough one that if I was still doing major open source work, I’d be working on that.
- steveklabnik 2y ago
  For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in response to review comments” development style is still very rebase centric, but not stacked. You also have to remember (though there’s no reason you should know this) that GitHub came out of the community I was heavily involved in at the time of its birth. I’ve been using GitHub for longer than most people, and so the PR-style workflow has been the air I’ve breathed for so long, it can be hard to understand other things at first. I had used subversion before git, but didn’t really understand much about it. Anyway, that’s just a roundabout way of saying that I think this space is super interesting because these tools are so flexible that they can be used in so many different ways, and it’s easy to assume that “how you use git” is some sort of shared experience when that’s not really true.
jFriedensreich 2y ago
I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI concept as starting point)
- sheremetyev 2y ago
  for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen https://martinvonz.github.io/jj/latest/sapling-comparison/ https://martinvonz.github.io/jj/latest/sapling-comparison/
  - hinkley 2y ago
    If first class resolution is done right, then instead of project generators we can just create sample projects that people fork, and when you make breaking changes or add new startup config to the project, you update the sample project(s) and people can pull the updates. Once you resolve the conflicts you’re done until the next change, at which point your repo remembers how the last conflict was resolved, and doesn’t ask you to redo it. This is why jj is on my todo list. I’m not calling it jujutsu no matter how much someone pays me though.
- steveklabnik 2y ago
  I think it’s great that there is more than one project in this space. Sapling is pretty cool too, though I haven’t used it as much. And yeah, the lack of good review tooling is certainly a big issue.
- aseipp 2y ago
  Gerrit, as I like to say, has a user interface that only a mother could love. But ultimately it's a very productive tool, so I just got over it. I even wrote some integration between jj and gerrit, making submitting stacks very easy and smooth. IMO, Gerrit is the best currently available option by a large margin, notwithstanding its quirks.
forrestthewoods 2y ago
I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta. I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho. I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas. My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.
- aseipp 2y ago
  I used Sapling for many months before switching to JJ. In my mind -- and I'm insanely biased as I am a JJ developer at this point -- they are both leagues ahead of Git, but I think JJ's Git interop, conflict handling, and general UX make it much more powerful and general than Sapling. Conflict handling alone is leagues better. (Martin worked on version control for a long time, and JJ is a tool that can only be created by someone with deep expertise in the domain, which I think shows itself over and over again in its use.) If you are already using Sapling then at least trying it should be fairly easy and familiar. You could also write a JJ backend for Mononoke and EdenFS if you wanted and then use it at work ;) You wouldn't be the first JJ user from Meta, actually... We do have plans to explore server-side designs with virtual filesystems, chunked storage, etc. There's nothing concrete yet. (Another benefit is that JJ is much easier to write patches and contribute to due to being a relatively new, small Rust project, whereas Sapling is much more developed but much bigger and harder to get into, I think.)
  - forrestthewoods 2y ago
    JJ's conflict handling seems nice. Can't say that it's a big enough problem for me to qualify as a "major feature", but a seemingly nice improvement. I'm not sure how I feel about JJ's "working copy commit". One of the great things about Meta VCS is that all commits are automatically backed up into the cloud. Which seems incompatible with the JJ model? Not sure. I think the D in DVCS is *wildly* overrated. 99.999% of projects are defacto centralized. I'm #TeamMonoRepo 100% of the way. My background is gamedev and perforce. An industry which still uses Perforce because Git is poopy poop poop. The Git integration I want to see is the ability to easily sync a monorepo subfolder with an external GitHub repo. Syncing commits for internal projects that are open sourced requires a big ugly custom set of tooling. And I'd kind of like a way to do an "inner fork" within a monorepo if that makes sense. If you're interested here's a pair of blog posts I wrote that have at least some of my thoughts on source control. https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/ https://www.forrestthewoods.com/blog/dependencies-belong-in-... https://www.forrestthewoods.com/blog/using-zig-to-commit-toolchains-to-vcs/ https://www.forrestthewoods.com/blog/using-zig-to-commit-too...
thih9 2y ago
Love it, read a couple of chapters already and planning to finish the rest. As a person completely new to jj and someone who also enjoys git CLI, this is an intuitive, very useful and enjoyable read. I’m especially interested after learning about the git compatible backend: > There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without anyone else you're working with to convert too.
- steveklabnik 2y ago
  Thank you!
nextaccountic 2y ago
Can someone sometimes use jj and sometimes use git in the same repo?
- martinvonz 2y ago
  Yes: https://martinvonz.github.io/jj/latest/git-compatibility/#co-located-jujutsugit-repos https://martinvonz.github.io/jj/latest/git-compatibility/#co...
stavros 2y ago
This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapshots", but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.
- steveklabnik 2y ago
  Thanks for the feedback! I think these terms are used a bit loosely, even though I try to be precise about it. Your mental model sounds decent. I think there’s a few ways to describe things. I like to think of changes as a stable ID for something I want to accomplish, and a commit as the intermediate steps that make up a change. You can kind of think of a change as a branch… but I think that’s stretching it.
  - stavros 2y ago
    Ahh, this really helps. I think you should definitely mention that a change consists of commits (unless it already is and I missed it). This helps because the two questions I had before were "if I change some text, will the change ID change too?" and "does a commit end a change?". Clarifying early on what exactly a change ID is, when it changes, and what the relationship between changes and commits is would really help, I think.
  - stavros 2y ago
    OK, going through the tutorial again, I think the difference between commits and changes are definitely the thing to focus on. Before your comments, I felt like I was building on a small foundation, because I didn't understand how commits and changes relate, and didn't have a good mental model of them. After your comments, the entire tutorial is more solid, but still I feel like I have gaps. My feedback would be to really focus on commits vs changes and define their relationships, what affects them, etc before you go into anything else.
- 2y ago

158 points by 80x86 2y ago

Steve, I see you’re in this thread. I was using jj for a while before reading your tutorial and yet still found it quite insightful and helpful. Thanks for your contribution!

steveklabnik 2y ago
You’re welcome!

deleted 2y ago

[deleted]

drudru 2y ago

Steve wrote this in a very approachable style. It is the first time I really understood what 'jj' is about. I'm actually kind of excited to start using this tool with my git repos.

steveklabnik 2y ago
Thanks so much! Just want to point out that this hasn’t been updated in a minute, and in particular, you’ll get some messages about branches being bookmarks now: https://github.com/steveklabnik/jujutsu-tutorial/pull/34 https://github.com/steveklabnik/jujutsu-tutorial/pull/34 I have started on a second iteration of the tutorial in private, and am gonna see if I can get it in shape this weekend. Happy to answer questions about jj!
- drudru 2y ago
  Thank you Steve! Really enjoying this tutorial. No questions so far.
- emmelaich 2y ago
  Does "in a minute" mean "not for a long time"? Because that's how my kids use that phrase. English is so great and so confusing!
  - stackghost 2y ago
    It means both "in a long time" and "in a short time", depending on context and intonation.
    - steveklabnik 2y ago
      Yep, isn’t language grand?
- nchmy 2y ago
  I've been meaning to figure out JJ for a few months now. Part of why I havent was that your tutorial is a bit out of date. I can't wait for a revamp!
  - steveklabnik 2y ago
    Well hopefully I can fix that!
miguelxpn 2y ago
No surprises there. Steve has always been a great writer.

nixosbestos 2y ago

One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.

emmanueloga_ 2y ago
Helix, the editor? How would you pitch it? Zellij looks powerful but also a bit too complex, following the "kitchen sink" school of design :-). No biggie but its name is too close to IntelliJ imho. What kind of workflow do you use with it? I used tmux a bit back in the day, but these days I feel like good old tabs and app windows cover my needs. When I want to multiplex processes in a single window, I reach for Overmind. [1] -- 1: https://github.com/DarthSim/overmind https://github.com/DarthSim/overmind
- Lyngbakr 2y ago
  > Helix, the editor? How would you pitch it? Not the OP, but Helix is a minimal fuss modal editor with sensible defaults. My config is maybe five lines? I say "maybe" because I haven't looked at it I first wrote it. And I think I'd probably be just fine with no config.
  - imjonse 2y ago
    Sensible defaults but also out of the box features you only get in vim by finding and configuring external plugins (fuzzy file picker, LSP integration, multi-cursor editing, inline keymapping help). Cons: no session save, good Helix keybindings not available in other tools so confusing to switch between vim/hx mental models when in colab/vscode, no AI-assistants since no plugin system yet.
- stavros 2y ago
  I don't know what you find complex about Zellij, as I haven't used it extensively, but the few times I've used it, the UI was eminently self-describing, I managed to do everything I've needed to do within a minute of first launching it. Is there more advanced stuff that's more complex that I just haven't seen?

38 2y ago

Jujutsu is terrible in my opinion. people hate the index, but I think they just dont get it. to me a commit is something that is ready to push, and the index is for stuff that is done but not ready to push. just because I wrote one line that I am happy with, doesn't mean I am ready to commit and push that. I prefer to add stuff thats done, then when enough is done I can commit and push. if you remove the index it makes it too easy to push half done stuff

steveklabnik 2y ago
I like jj because I like git's index so much. JJ lets me do what git's index does, but in a much more powerful way. What you do is, you treat @ like the index, and you work on @-. This is the "squash workflow" https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
- 38 2y ago
  [flagged]
  - steveklabnik 2y ago
    https://steveklabnik.github.io/jujutsu-tutorial/hello-world/viewing-contents.html https://steveklabnik.github.io/jujutsu-tutorial/hello-world/... > The very first character at the top left is an @. @ is a special name for "whichever commit the working copy reflects." At first I kind of thought about it like HEAD in git, but that's not correct: HEAD is the most recent commit, but @ represents the working copy, which may be "dirty" from git's point of view. This is our first glimpse into the power of the index-less workflow, though we'll explore that fully in the next chapter. For this moment, just realize that we have one less concept, but haven't actually lost any of its power.
    - 38 2y ago
      OK but again thats awful, because @ IS A COMMIT, so you are only a "git push" away from accidentally pushing arbitrary garbage instead of proper changes

chaostheory 2y ago

I get that naming is one of the hardest problems in computer science, but naming software after a martial art is just lazy and will lead to problems with things like searches

red_admiral 2y ago
Like naming your language after a common two-letter verb. At least we can search for 'golang'.
riwsky 2y ago
If it helps, they actually named it after their desired CLI abbreviation: > The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
- gcarvalho 2y ago
  And the martial art is jiu-jitsu, not jujutsu. Similar sounding but definitely not “named after”.
  - yencabulator 2y ago
    No it's not, but so far the Brazilians are still sticking with the incorrect ~1908 way of writing it. Standard Japanese pronunciation for "jutsu" does not contain an i, and it's also judo not "jiu-do" that the old system would have called for. https://en.wikipedia.org/wiki/Jujutsu#Etymology https://en.wikipedia.org/wiki/Jujutsu#Etymology
stavros 2y ago
I guess it's lucky they misspelled it, so there's no conflict.
- martinvonz 2y ago
  I would have spelled it "jiu-jitsu" if I had not looked up the spelling first and found that Wikipedia decided to spell it "jujutsu" (https://en.wikipedia.org/wiki/Jujutsu https://en.wikipedia.org/wiki/Jujutsu). Maybe I trusted Wikipedia too much; I have never practiced jujutsu/jiu-jitsu myself.

aos 2y ago

I’ve started to use jj much more often (and actually used this tutorial to get me started!). I do wish its interaction with Nix flakes is less annoying though, but that’s not the fault jj.

spott 2y ago
How is it annoying?

cyanf 2y ago

thank you steve, i’ve been excited for this!

steveklabnik 2y ago
You’re welcome!

itohihiyt 2y ago

Came here for a martial arts tutorial, which I thought was a bit weird to see front page on HN, and now I see an alternative to git. I don't particularly like git and for personal projects use fossil instead. Without going through the whole tutorial, and doing a lot more reading, why should I consider using this over fossil?

kettleballroll 2y ago
Same. I miss the old times when people tried naming their projects sensibly. I mean, we're constantly telling ourselves how variable and function names should speak for themselves, but then we name our projects using random, completely non-descript names. It's a annoying.
- chronial 2y ago
  Which old times are you referring to / what are "sensible" names? I thought about it and I don't know what a better name would be. Off the top of my Head, I know Perforce, BitWarden, Subversion, fossil and git. And then the abbreviations CVS, RCS and SVN. Do any of these qualify as a descriptive name?
  - itohihiyt 2y ago
    As a British national I like to think git is a very descriptive name, because git is a git to use and understand.
    - batch12 2y ago
      For a US southerner it works too. We can use the tool to 'git' our code.
  - phrenq 2y ago
    At one point in my career, I used Microsoft SourceSafe, which is a pretty descriptive name. Seems like the exception here, though.
  - 2y ago

ZoomZoomZoom 2y ago

Would be great if it was Pijul that got Steve's attention. Sometimes it's all you need to achieve a lot.

cinntaile 2y ago
No updates since March 2024?
steveklabnik 2y ago
I’ll just be honest with you: Pijul never really caught my interest, but I always felt pretty neutral about it until I started noticing the project authors acting very snide and aggressive on here. That is not something I want to be around these days, and so I doubt I’ll ever try Pijul.
- ZoomZoomZoom 2y ago
  It's a little surprising to hear, from what I've seen here there's not much besides the usual whiff of academical loftiness, but nothing that I'd qualify as aggression. What caught my interest: * Separate operations and data * Partial repos = no big repo issues, no need for shallow clones and such * Proper and easy merging with no shuffled lines * Patch-based model is much more intuitive (e.g. rebase and merge are the same operation) * Conflict resolutions are stored and can be reapplied!

lawn 2y ago

I really like Jujutsu but I went back to Git because there wasn't a Neovim plugin with features comparable to Neogit or Fugitive. I even started writing one but that was a pretty big project and I lost the motivation for it.

steveklabnik 2y ago
I’ve heard people say similar things about magit. Tooling matters a lot, for sure.

red_admiral 2y ago

I expected actual Jujutsu :) I recommend looking up Bartitsu (that Conan Doyle spelled Baritsu), a short-lived but very interesting martial art.

klauserc 2y ago

Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")

conaclos 2y ago
> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?
- abhinavk 2y ago
  No from what I see. It does that whenever you run any jj command. I haven't checked the source.
  - sheremetyev 2y ago
    by default snapshotting happens on each jj command additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman https://martinvonz.github.io/jj/latest/config/#watchman
- aseipp 2y ago
  It's a bit of a magic trick. A "snapshot" is taken any time a command is run, and it happens implicitly before any actual algorithms or code for a given command is run (massively simplifying the internal design), so for all intents and purposes it's "automatic" from the user interface e.g. even checking repo status or otherwise small operations will cause a snapshot. But you can integrate with https://github.com/facebook/watchman/ https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.

videlov 2y ago

Martin (the jj creator) recently gave a talk at the Git Merge 2024 conference: https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G

leighleighleigh 2y ago

It's my first time encountering your writing Steve, loved it! Time to give JJ another crack...

steveklabnik 2y ago
Glad to hear it!

swiftcoder 2y ago

> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

arccy 2y ago
because it's a name that describes the technical implementation, not the end user experience
- swiftcoder 2y ago
  Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.
  - steveklabnik 2y ago
    This is a major issue for sure. Like a big enough one that if I was still doing major open source work, I’d be working on that.
steveklabnik 2y ago
For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in response to review comments” development style is still very rebase centric, but not stacked. You also have to remember (though there’s no reason you should know this) that GitHub came out of the community I was heavily involved in at the time of its birth. I’ve been using GitHub for longer than most people, and so the PR-style workflow has been the air I’ve breathed for so long, it can be hard to understand other things at first. I had used subversion before git, but didn’t really understand much about it. Anyway, that’s just a roundabout way of saying that I think this space is super interesting because these tools are so flexible that they can be used in so many different ways, and it’s easy to assume that “how you use git” is some sort of shared experience when that’s not really true.

jFriedensreich 2y ago

I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI concept as starting point)

sheremetyev 2y ago
for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen https://martinvonz.github.io/jj/latest/sapling-comparison/ https://martinvonz.github.io/jj/latest/sapling-comparison/
- hinkley 2y ago
  If first class resolution is done right, then instead of project generators we can just create sample projects that people fork, and when you make breaking changes or add new startup config to the project, you update the sample project(s) and people can pull the updates. Once you resolve the conflicts you’re done until the next change, at which point your repo remembers how the last conflict was resolved, and doesn’t ask you to redo it. This is why jj is on my todo list. I’m not calling it jujutsu no matter how much someone pays me though.
steveklabnik 2y ago
I think it’s great that there is more than one project in this space. Sapling is pretty cool too, though I haven’t used it as much. And yeah, the lack of good review tooling is certainly a big issue.
aseipp 2y ago
Gerrit, as I like to say, has a user interface that only a mother could love. But ultimately it's a very productive tool, so I just got over it. I even wrote some integration between jj and gerrit, making submitting stacks very easy and smooth. IMO, Gerrit is the best currently available option by a large margin, notwithstanding its quirks.

forrestthewoods 2y ago

I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta. I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho. I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas. My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.

aseipp 2y ago
I used Sapling for many months before switching to JJ. In my mind -- and I'm insanely biased as I am a JJ developer at this point -- they are both leagues ahead of Git, but I think JJ's Git interop, conflict handling, and general UX make it much more powerful and general than Sapling. Conflict handling alone is leagues better. (Martin worked on version control for a long time, and JJ is a tool that can only be created by someone with deep expertise in the domain, which I think shows itself over and over again in its use.) If you are already using Sapling then at least trying it should be fairly easy and familiar. You could also write a JJ backend for Mononoke and EdenFS if you wanted and then use it at work ;) You wouldn't be the first JJ user from Meta, actually... We do have plans to explore server-side designs with virtual filesystems, chunked storage, etc. There's nothing concrete yet. (Another benefit is that JJ is much easier to write patches and contribute to due to being a relatively new, small Rust project, whereas Sapling is much more developed but much bigger and harder to get into, I think.)
- forrestthewoods 2y ago
  JJ's conflict handling seems nice. Can't say that it's a big enough problem for me to qualify as a "major feature", but a seemingly nice improvement. I'm not sure how I feel about JJ's "working copy commit". One of the great things about Meta VCS is that all commits are automatically backed up into the cloud. Which seems incompatible with the JJ model? Not sure. I think the D in DVCS is *wildly* overrated. 99.999% of projects are defacto centralized. I'm #TeamMonoRepo 100% of the way. My background is gamedev and perforce. An industry which still uses Perforce because Git is poopy poop poop. The Git integration I want to see is the ability to easily sync a monorepo subfolder with an external GitHub repo. Syncing commits for internal projects that are open sourced requires a big ugly custom set of tooling. And I'd kind of like a way to do an "inner fork" within a monorepo if that makes sense. If you're interested here's a pair of blog posts I wrote that have at least some of my thoughts on source control. https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/ https://www.forrestthewoods.com/blog/dependencies-belong-in-... https://www.forrestthewoods.com/blog/using-zig-to-commit-toolchains-to-vcs/ https://www.forrestthewoods.com/blog/using-zig-to-commit-too...

thih9 2y ago

Love it, read a couple of chapters already and planning to finish the rest. As a person completely new to jj and someone who also enjoys git CLI, this is an intuitive, very useful and enjoyable read. I’m especially interested after learning about the git compatible backend: > There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without anyone else you're working with to convert too.

steveklabnik 2y ago
Thank you!

nextaccountic 2y ago

Can someone sometimes use jj and sometimes use git in the same repo?

martinvonz 2y ago
Yes: https://martinvonz.github.io/jj/latest/git-compatibility/#co-located-jujutsugit-repos https://martinvonz.github.io/jj/latest/git-compatibility/#co...

stavros 2y ago

This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapshots", but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.

steveklabnik 2y ago
Thanks for the feedback! I think these terms are used a bit loosely, even though I try to be precise about it. Your mental model sounds decent. I think there’s a few ways to describe things. I like to think of changes as a stable ID for something I want to accomplish, and a commit as the intermediate steps that make up a change. You can kind of think of a change as a branch… but I think that’s stretching it.
- stavros 2y ago
  Ahh, this really helps. I think you should definitely mention that a change consists of commits (unless it already is and I missed it). This helps because the two questions I had before were "if I change some text, will the change ID change too?" and "does a commit end a change?". Clarifying early on what exactly a change ID is, when it changes, and what the relationship between changes and commits is would really help, I think.
- stavros 2y ago
  OK, going through the tutorial again, I think the difference between commits and changes are definitely the thing to focus on. Before your comments, I felt like I was building on a small foundation, because I didn't understand how commits and changes relate, and didn't have a good mental model of them. After your comments, the entire tutorial is more solid, but still I feel like I have gaps. My feedback would be to really focus on commits vs changes and define their relationships, what affects them, etc before you go into anything else.
2y ago