Jujutsu: A Next Generation Replacement for Git

https://www.vincentschmalbach.com/jujutsu-a-next-generation-replacement-for-git/

by vincent_s • 2 years ago

94 80 2 years ago

vincentschmalbach.com

keikobadthebad• 2 years ago

stgit...

childintime• 2 years ago

https://stacked-git.github.io/

setheron• 2 years ago

Honestly nothing of substance here. Would be great to get a first hand account of jj in practice.

chaychoong• 2 years ago

I have a short blog post here that describes some of my basic workflows:

https://blog.chay.dev/basic-jj-workflows

viraptor• 2 years ago

How do people work with jujutsu and hacks/secrets? Having no staging feels like a disaster magnet to me where things that should never be published have a chance to be saved and distributed by accident. I consistently have some temporary workarounds / scripts / credentials / logs hanging around my repos while I work on things. I think I'd have to change my approaches significantly to use this safely.

xlii• 2 years ago

In short commit is your stage.

It’s expected that you look at the commits before you push, the same as you do with staging. If you’d just "commit -am" the results would be the same.

And since a commit can branch you can have a multiple (conceptual) stages.

Jujutsu respects gitignore but cannot be told to not track in-file changes. Annoying when your peers commit customization files into the repository.

hoseja• 2 years ago

Targeted to the always online generation that does this automatically, probably. Whips in the soul.

35235829084• 2 years ago

I am a fan of the dev branch strategy [1], where I have a specific commit that holds all my customizations that I rebase off of. This blog post has it set up such that git automatically ignore pushing the dev commit, but I haven't really gotten that far yet. I just rebase my branch off current main when I'm ready to push.

[1] https://reasonablypolymorphic.com/blog/jj-strategy/index.htm...

aseipp3• 2 years ago

Things like logs are just generally ignored in gitignore so they can just be there or whatever. In practice this hasn't been a huge problem for me.

Hacks/workarounds/etc are actually pretty easy to handle and there are a couple strategies. The one I use is to use a merge commit. Let's say you have a patch P that you want to keep private (it hardcodes some build settings you like to use or whatever) and a patch A you want to work on. The base these changes are based off is B which is the upstream branch "main".

Then, you create a merge between A and P, creating commit M, and your working copy (called @ or "at") sits on top:

       --> P -->
      /         \
    B (main)     M --> @
      \         /
       --> A -->

And now, both `P` and `A` exist in your repository at the same time. Now, you can just use the `jj squash` command to take changes from `@` and put them inside either A or P, as you do your work, thus moving them "through" the merge commit M. These kinds of techniques where you move changes between commits are very common in Jujutsu so this is pretty natural once you get used to it.

Note that you can also have `M = @`, i.e. the merge commit is the working copy itself. I prefer to keep the commit M separate and work "on top" of it like in the above graph, because you may solve a conflict between P and A, and M would be the correct place to put it, and you would want to keep it separate from everything else.

A neat feature of this trick is that you can create a branch for change `A` and if you are sitting on top of `M`, and you run `jj git push`, then only `A` will be pushed and `P` will be ignored and left alone. In fact `P` will never be pushed unless you explicitly ask for it by creating the branch pointing to it. Nor is the merge commit ever pushed anywhere; it only exists so that you can have both changes available locally.

I do this all the time these days in various forms, and in practice, the day-to-day stuff isn't terribly different than it is when you just leave things out of the staging area inside your working copy.

bdcravens• 2 years ago

While this is just a blog article, which is fine, I think the intended audience isn't sold on being told to run a couple of commands and install a mystery binary. (especially for those not already familiar with the Rust ecosystem and package manager)

The actual project website is here: https://martinvonz.github.io/jj/latest/

The repo is https://github.com/martinvonz/jj

Note: the project author is a Googler, and it appears to be under the umbrella of Google/Alphabet, as a CLA is required: https://martinvonz.github.io/jj/latest/contributing/

wodenokoto• 2 years ago

I’m as interested in the next git as much as the next guy, but this gives me no idea how I should or could work with jujutsu.

Anonymous branches? How do I get back to my work?

Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history?

I have no impression of how this makes anything easier.

yawaramin• 2 years ago

I think this is just the hallmark of a new technology. Nobody understood how (or why) to use git when it first appeared either until people showed up who could communicate its benefits and UX really well.

ahartmetz• 2 years ago

Git, though, has the somewhat unique problem that its UX does a particularly bad job of explaining itself. Git isn't difficult because of its mind-bending awesomeness, but because the UX sucks. I'm fine with it, thankyouverymuch, but it was rote learning and I watch beginners struggle.

steveklabnik6• 2 years ago

Anonymous branches? How do I get back to my work?

I fully appreciate this question, as I was there too until I started working with anonymous branches.

Here's some sample output from jj log:

    $ jj log --limit 5
    @  pzoqtwuv steve@steveklabnik.com 2024-03-01 15:06:59.000 -06:00 9353442b
    │  added some cool new feature
    │ ◉  xrslwzvq steve@steveklabnik.com 2024-02-29 23:06:23.000 -06:00 a70d464c
    ├─╯  create hello and goodbye functions
    │ ◉  yykpmnuq steve@steveklabnik.com 2024-02-29 23:03:22.000 -06:00 210283e8
    ├─╯  add better documentation
    ◉  ootnlvpt steve@steveklabnik.com 2024-02-28 23:26:44.000 -06:00 b5db7940
    │  only print hello world
    ◉  nmptruqn steve@steveklabnik.com 2024-02-28 23:09:11.000 -06:00 90a2e97f
    │  refactor printing

Here, we are working on change 'pzoqtwuv'. (@ means the working copy.) There are colors in the real CLI to make the differences more obvious, and to show you unique prefixes, so for example, you probably only need 'p' or 'pz' instead of 'pzoqtwuv' to uniquely identify the change. I'll use the full IDs since there's no syntax highlighting here.

We have two anonymous branches here. They have the change IDs of 'xrslwzvq' and 'yykpmnuq'. The log output shows the summary line of their messages, so we can see "create hello and goodbye functions" on one branch, and "add better documentation" on the other.

You don't need an additional branch name: the change ID is already there. If you want to add even more better documentation, 'jj new yykpmnuq' (or again, likely 'jj new yy' in practice) and you're off to the races. (jj new makes a new change off of the parent you specify.)

That's all there is to it. We already have the commit messages and IDs, giving an additional identifier doesn't help that much.

(And if you're in a larger repo with more outstanding branches, you can ask 'jj log' to show specific subsets of commits. It has a powerful DSL that lets you do so. For example, say you only want to see your commits, 'jj log -r 'mine()'' can do that for you.)

Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history?

The simplest answer is "you put that stuff in your .gitignore and it never gets committed." That said, it is recognized that sometimes that is not possible or easy. See https://github.com/martinvonz/jj/issues/323 for the current discussion about how to maybe support alternatives here.

I have no impression of how this makes anything easier.

My take on this is that jj has fewer but also more orthogonal concepts. Naming things is hard. I don't like to do it. Not needing to name branches is really nice, as I don't really lose anything by not naming them, and I no longer have to name them.

With regards to some other stuff, the "auto commit of saved files" really means that jj turns two of git's concepts, commits and the index, into one concept: commits. How is that easier? Well, I don't need to learn two sets of tools for dealing with the index vs a commit. For example, git has two kinds of resets: hard and soft. This is because git needs to have two sets of behaviors to deal with both concepts here, as git reset is about changing the index but maybe or maybe not the working tree. All of these distinctions don't matter in jj, because it's all just commits, so you use regular old tools on commits for them.

lifeformed• 2 years ago

What I want with a new git is first class support for large binary files. It's essential in game dev, and the best solution seems to be git lfs, which has its own problems.

martinvonz6• 2 years ago

I hope we'll be able to do better once we have an open-source storage backend that stores contents in a central database (like we do with Jujutsu at Google).

dastbe• 2 years ago

is there any active work on an oss storage backend? any blockers in the jujutsu codebase to starting one?

reverius42• 2 years ago

This is what we’re building https://xethub.com for! It’s a git forge with better support for large files (using git-xet instead of git-lfs) and it’s designed to store source code and binary assets in the same repo.

Disclaimer: I work at XetHub.

snthpy2• 2 years ago

I saw a youtube talk on this a year or two ago and it looked promising. I've been waiting to see more people take it up and sing its praises. This is the first HN post I've noticed since then.

Any experiences of anyone trying it out and switching over to it?

snthpy2• 2 years ago

I think this was the talk: https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf

I would like to know more about the first class conflict handling. That could potentially be useful for an application I have in mind but I need to understand the algorithms better. How does it compare to CRDTs or other merge strategies?

stouset5• 2 years ago

The easiest way to think about it is that merge conflicts aren't something that causes operations to be aborted like they are in git. If you have a merge conflict or a rebase, conflict markers are inserted and everything continues.

You can quickly see any commits that have merge conflicts. If some operation introduced them, you can go edit that commit and fix them. When you do so, the fix propagates forward automagically to all descendant commits. The benefit here is that the operation you were trying to do fully completes and you're never ejected into an intermediate state where changes are dropped into your working copy and you're expected to fix it right here and now before anything else happens. You don't have to unwind everything because you screwed up an earlier conflict resolution since everything is stored in history; you just go back to the commit you want to fix, make a change, and then jump back to the later commit that still needed some work.

35235829084• 2 years ago

It's been my daily driver for the last 3 months, and it's really amazing. Highly recommend trying it out!

stouset5• 2 years ago

I expected it to be a bigger migration than it was. But I was using it effectively as a complete git replacement the very first day.

I still had a few things I didn’t know how to do optimally, but it was close enough to be productive. Within a week I’d closed basically all of the gaps.

It’s been three or so months now and I’m never going back. It’s been so transformative I can barely remember all the innumerable frustrations and papercuts I used to put up with daily. Rebase conflicts. Juggling the stash. Ugh. I say this as someone who considered themselves extremely proficient with git. I mean, I wrote a compatible Ruby implementation of it over a decade and ago.

If it gains momentum, jj has a better chance than anything I’ve seen at finally dethroning git.

steveklabnik6• 2 years ago

It took me like a week to get the hang of it. Haven't gone back to git since.

donatj• 2 years ago

One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes.

With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history.

If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.

aduwah• 2 years ago

Same here, I am doing a mess between commits, copying and comparing random files, hardcoding secrets for a quick test... To think that it ends up upstream is a thing of nightmares.

I know, gitignore could help, but it eliminates the convenience of being flexible/quick&messy.

martinvonz6• 2 years ago

This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-i.... I'm guessing you didn't click that link. I suppose we need to inline part of the text where we link to it to reduce the number of confused readers.

At this point, I wonder if maybe we should not even mention the staging area. It seems to confuse a lot of people, so maybe it hurts more than it helps to mention it.

martinvonz6• 2 years ago

Oh, I should also say that we have https://github.com/martinvonz/jj/issues/323 for your concern about automatically tracking files.

35235829084• 2 years ago

I use Jiujitsu, and my personal experience is that the basic "write code, git add what specifically I want to history" flow is the same. The working commit is the effective staging area and it doesn't get forever committed to public history. Without going too much in detail, the working commit can't be pushed to your remote, similar to how the staging area can't be pushed.

smazga• 2 years ago

Could you explain that just a bit more? I'm trying to figure out how to adapt my personal workflow to jujutsu and this is the part that confuses me.

I think it's me not understanding the difference between "jj new" and "jj commit", but I'm not sure.

I'm a big fan of the staging area for crafting clean commits, so this would be super useful for me to understand.

aseipp3• 2 years ago

There isn't an "explicit" staging area in the sense it's a separate semantic concept that is distinct from a "commit"; rather, the provided machinery for working with commits can be used to do all the things you do with the staging area. The staging area is subsumed as a concept by another concept. By the same token, it also subsumes the stash too. In other words, you can do all the same workflows you do now, but there are fewer "nouns" to juggle. In Git there's the working copy, staging area, and commits. In Jujutsu, there are only commits, and commits are used in more generalized ways with more generalized operations.

To put it another way: the staging area is great because it's really easy to manipulate and "chop it up" as you like. If you make commits themselves really easy to manipulate, just as easy as the staging area, then you can just get rid of the staging area and use commits instead i.e. split a commit in two, or squash two commits together, or parallelize them or reorder them, etc. This actually means that many workflows in Jujutsu are more open ended and flexible than the Git equivalents, while simultaneously having less nouns (which means that, for example, there are fewer UX irregularities because there's less surface area.)

The README that Martin mentions first says there's "no staging area", but then a few paragraphs later mentions that the working copy concept subsumes it and so it provides a superset of functionality. That should probably be rewritten.

npsimons• 2 years ago

I don't want half finished changes forever committed to history.

This is exactly why I hew to squash+rebase. As I like to put it "I don't care about every little sneeze a developer had." Git has spoiled me with this, where I have the power to commit to my private repo anything I damn well please, but in the end I can clean things up and keep the central repo clean and bisectable[0].

Any VCS that doesn't offer these (squash, rebase, bisect) is a complete non-starter for me.

[0] https://blog.carbonfive.com/always-squash-and-rebase-your-gi...

ramblerman• 2 years ago

To basically never just "git add ." whatever might just happen to be different in their work area
I will start to commit change sets as parts of the code solidify without committing other less solid changes

I feel like you are pushing your idiosyncratic way of working on others. It's great that you have a way that works for you, but it seems rather odd to me that you would ever be working on more than one thing in the same staging area.

I always git add -a . because I'm working on one specific thing, and my tests just passed.

s1gsegv• 2 years ago

The thinking is that you might’ve instrumented other code or de optimized it in a way that you don’t want to commit while solving the problem.

thebruce87m• 2 years ago

You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?

v3ss0n3• 2 years ago

This getting spammed but developers .. they are afraid to change from git . Mercurial was much better than git in workflow and architecture wise and nobody care enough due to GitHub popularity. This will go the same , as well as sapling.

stouset5• 2 years ago

As a counterpoint, jj has extremely good git interoperability.

I and another teammate have switched over for several months and nobody on our team needs to know or care.

krick6• 2 years ago

Props to you, but this doesn't change my mind. VCS is intrinsically meant as a collaboration tool. If something goes wrong "jj did it" won't be a good excuse. If one needs to communicate his workflow to another, he better doesn't start with "well, you just install jj and...", he needs to explain, how to do that in git. If there is a junior dev on the team and I need to teach him common practices, I need to do that in the same personal-preference-agnostic manner, so I shouldn't teach him jj instead of git, even if I use it personally. Long story short, you need to be fluent in both, and even though I know git pretty well, I wouldn't even say I'm fluent in git: most of the time my fingers type stuff I don't conciously remember anymore, often relying on aliases and Ctrl+R. This is additional complexity, and it feels to me like I need it to be something HUGE to actually justify that.

v3ss0n3• 2 years ago

Good for you that you have only one team mate. I have 15 of them at varying skill levels. As organization grew bigger Murphy laws kicks in. We love mercurial but we have to change because the whole world had move to git and developer need to learn two different collaboration tools and then even mercurial hg-git ext works well we have to move away from it.

aseipp3• 2 years ago

Jujutsu supports using Git repositories as the underlying repo format, in fact you can even run most of your `git` commands in the exact same repository -- and it is otherwise unnoticeable to anyone beyond yourself, barring customized setups. And we're committed to supporting and improving our Git integration, as long as Git is useful, and our users need it. We're not going anywhere :)

stackskipton• 2 years ago

I wouldn't say afraid but don't see the reason. Vast Majority of Developers are working where repo = single application and their git workflow is Scaled Trunk Based: https://trunkbaseddevelopment.com/#scaled-trunk-based-develo... main, branch, work, merge, repeat and they almost always fix forward.

Also, Rebasing is cause for Dev Riots because of nightmare merge conflicts that can result.

Since the author is from Google, my guess is they are seeing issues that hit the level of "WE MUST FIX THIS" that only arise at Google Monorepo size.

steveklabnik6• 2 years ago

My current project is mostly a solo project. I do trunk based development. I still prefer jj these days.

hakube2• 2 years ago

why does Git need to be replaced?

krick6• 2 years ago

This. It's not like we are looking for something slightly better than git in some opinionated way. There's plenty better than git. Mercurial is better than git and as old as git. Git won. Everybody uses git. Everyone who knows, how to use git, is mostly comfortable using git. At this stage we either need something ground-breaking (and I don't quite imagine what this cold be in the context of VCS - even truly semantic conflict resolution barely cuts it, while simultaneously being pure unattainable magic), or I don't think this is gonna float. I don't need it. Who needs it?

It's a relatively easy thing to adopt something you don't need, when you are the only person involved. But VCS is pretty much in the same category as instant messaging and social network platforms are. In a sense, maybe it is a social network platform. I don't see it happening and I highly doubt I would want it to happed, even if I knew this jj stuff better.

ezst2• 2 years ago

Git won because GitHub turned the whole contribution model into a resume-making social media game. The first generation on GitHub pressured the second one into using it at a time when the DVCS scene was still nascent (and git's many flaws, more excusable), and the second one, now turned into a critical mass, made it acceptable for the next to just cargo cult a few commands instead of learning their VCS, because that was the bare minimum to _partake in the game_, and an acceptable trade-off to deal with a now objectively user-hostile and inferior tool.

The nice (and quite unique) thing about jj is that it takes all the good cues from systems which kept improving (and in particular, from mercurial), and slaps them onto git without requiring a storage model change, practically offering the social "perks" of GitHub (by being fully compatible with it), with no-compromise. And to be honest, at this point, there isn't much reason for a new comer to learn git rather than jj, and that's a wonderful news in my book.

xigoi2• 2 years ago

As far as I can tell, Jujutsu solves this problem by being compatible with Git.

sunshowers4• 2 years ago

Jujutsu has Git as a supported backend, so it does not need network effects to succeed. I was using it full time at Oxide for many months before anyone else was aware of it.

More generally: I am more knowledgeable about version control than 99% of people (having worked on it full time for many years). The Git UI is well beyond papercut bad. Many advanced users use the rebase-interactive workflow, which is broken in numerous ways.

See my testimonial (top one on the page) for an example where Jujutsu's rethink of VCS basics leads to an incredibly coherent interface. Jujutsu is built by world-class developers who have spent many years working on other systems and drawing lessons from them, and it shows! https://martinvonz.github.io/jj/latest/testimonials/

If I were introducing version control to someone new, I would not be proud of introducing Git and would constantly apologize for it. I'd be proud of introducing Jujutsu.

lawn4• 2 years ago

Because there are several issues with it?

Terrible cli user experience and having to resolve the same rebase conflict again and again for instance.

And maybe because other tools do things better?

hakube2• 2 years ago

I have been using Git for 8 years and haven't had any bad experiences with CLI. And this one and other tools that are supposed to replace Git are better in what way? The only thing that's better in this is the conflict resolution but other than that, it doesn't offer that much.

pictur• 2 years ago

Git is already as simple as possible with its own commands. I feel like we are making simple things more complicated with tools like this. If I start using this tool instead of git, I will probably start doing something hacky at some point. I don't want that. I don't want a history that keeps changing and getting weird with the use of rebase/squash. I don't think conflicts are a problem as long as a single history is kept up to date properly with git. The smoother the history, the easier it is to merge.

Kuraj• 2 years ago

I don't think conflicts are a problem as long as a single history is kept up to date properly with git.

That is easy when you work alone. It becomes more difficult as your team grows in size.

lawn4• 2 years ago

Weird take as Git is making things much more complex than they need to be, which is proven by Mercurial and Jujutsu that are much more intuitive while being as powerful.

alberth• 2 years ago

Slightly OT: does anyone know why OpenBSD decided to build their own version of git, as opposed to using jujutsu (or another alternative)?

https://www.gameoftrees.org/

martinvonz6• 2 years ago

Jujutsu was started in late 2019. Got seems to have been started in late 2017. I have no idea why they didn't contribute to gitless instead of starting a new project.

MaximilianEmel2• 2 years ago

How does this compare to Pijul[1]?

[1] https://pijul.org/

MaximilianEmel2• 2 years ago

https://github.com/martinvonz/jj/commit/0525dc9d860a5fff6a97...

masfoobar• 2 years ago

I have come from various version controls in my life.

I remember CVS during my early Linux days. At work it was SourceSafe and around the 2010 era, worked for companies using TFS or SVN, etc.

Each one of these had there issues. Some had a better relationship with SVN than others. I did not mind it. However, I HATED SourceSafe! Glad to never touch that again!

When distributed version controls started to become a thing, I played with git, mercurial and bazaar before they were common. I liked them all better than SVN. Eventually I worked for a company using Mercurial but it wasn't long before git was the breadwinner and replaced practically everything else.

Personally, the only reason I ended up on git is because is solved the problem of doing local commits. Many times I was not on the internet or local network, but I can commit whenever I like and push when available to do so. This, for me, was a HUGE win!

Now, I dont have a reason to switch to something else. Its not comparable like moving from SVN to git. Could there be some cool or simpler features? Maybe. Regardless I hardly have issues with git overall to cause me to look about.

The only "issue" I have came across with git is its not great for large binary files, or for storing a collection of images, etc. For coding - its awesome.

I guess the only way I will starting considering alternatives is if the git team decide to make terrible choices.

Jujutsu: A Next Generation Replacement for Git

Related Stories