Chris Krycho

> recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/

Based in part on the parallels of their respective titles, this post may be similar enough in style to potentially be informative about Jujutsu: https://v5.chriskrycho.com/essays/jj-init/#outline

I've linked directly to the Outline/TOC in order to provide a more immediate overview of the post's content but there's also a chunk of more "philosophical" introductory text before the Outline: https://v5.chriskrycho.com/essays/jj-init/

The introductory text has parallels with the "Subversion Re-education" section of Spolsky's document--including the apparently mandatory (though stated in more reserved terms) reference to the effect the incumbent VCS has on one's brain: "just how weirdly Git has wired your brain". :D

As to the "why", to quote from the intro:

----

Jujutsu is two things:

(1) It is a new front-end to Git. This is by far the less interesting of the two things, but in practice it is a substantial part of the experience of using the tool today. [...]

(2) It is a new design for distributed version control. This is by far the more interesting part. In particular, [...] a few key concepts [...]:

(2.1) Changes are distinct from revisions: [...]

(2.2) Conflicts are first-class items: [...]

(2.3) The user interface is not only reasonable but actually really good: an idea borrowed from... literally every VCS other than Git.

----

As someone who reluctantly stopped…

https://v5.chriskrycho.com/essays/jj-init/

> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. In my experience, very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. The common rejoinder is that developers ought to learn how Git works internally — that everything will make more sense that way.

This is nonsense. Git’s internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model. This is a classic mistake for software developers, and one I have fallen prey to myself any number of times. I do not blame the Git developers for it, exactly. No one should have to understand the internals of the system to use it well, though; that is a simple failure of software design. Moreover, even those internals do not particularly cohere. The index, the number of things labeled “-ish” in the glossary, the way that a “detached HEAD” interacts with branches, the distinction between tags and branches, the important distinctions between commits, refs, and objects… It is not that any one of those things is bad in isolation, but as a set they do not amount to a mental model I can describe charitably. Put in programming language terms: One of the reasons the “surface syntax” of Git is so hard is that its semantics are a bit…

Yes. I have one repository, which is a fork of an OSS project, with a 7-way octopus merge of various patches I carry, and another 2-way merge on top of that one. Every week or two I pull the latest changes from upstream and I rebase all 9+ branches in a single command. If there are conflicts on any one of the parallel streams of work, I can trivially fix each conflict individually in any order I want.

Jujutsu does not treat merge commits any more or less special than non-merge "1-parent" commits. (We used to do this, actually, and occasionally special case merges, but most users found it very confusing.) This regularity means most commands work fine on merges. 'jj new X' is a new commit on top of X. 'jj new X Y' is a merge commit with X and Y as parents. 'jj new X Y Z...' is a 3-way merge, and so on and so forth for any number of commits. Similarly, 'jj rebase' can handle moving commits and preserving the graph structure no matter how many edges are involved in particular, and can add or remove parents from a given commit. This means that conceptually the jj commit graph is merely a simple, ordinary DAG, and operations are transformations on the DAG like you expect.

Actually, this exact workflow is beloved by many community members, and I guess I can take responsibility for popularizing it originally, the "Mega Merge" technique. Instant, easy rebase is an essential part of making this technique viable.

- https://ofcr.se/jujutsu-merge-workflow -…

Location: Monument (45min S of Denver), Colorado, United States Remote: Yes, only Willing to relocate: No Technologies: - TypeScript and JavaScript (including Node) - Rust - CSS, HTML Long ago, also Postgres. I have lots of front end infra/engineering effectiveness experience from my almost-5-year tenure working on LinkedIn.com, where I was the tech lead until a year ago. I built the Ember TypeScript team, got LinkedIn’s TS effort funded and was the tech expert for the effort—when other folks hit an area they couldn’t figure out how to write safe and accurate types for, they pinged me.

I also have significant experience with Rust education: I ran the New Rustacean podcast 2015–2019, and this summer I wrote a new chapter on async/await for the official Rust book (currently in revision!).

Looking for roles with a particular kind of impact on the world (https://v5.chriskrycho.com/journal/next/role/), but fairly wide open about the details—though I particularly love and excel at framework and API design, and open source leadership and ecosystem development. I also have a passion for, but am relatively new at, PL work.

As a bonus, I am a very good teacher, mentor, and public speaker; you can find a number of talks by me on YouTube, including most recently at StaffPlus New York (https://www.youtube.com/watch?v=VkSGJdPyLxQ).

A while ago I remember reading about this new VCS project Jujutsu (jj) that claimed to be both simpler and more powerful than git. A bold claim! Didn't really think much of it at the time beyond well this is interesting.

But later, about 9 months ago, Chris Krycho published this lovely blog post[1] about jj and a thread about it was quite popular on HN. Again, really interesting, but not something I was going to dig into.

Finally, I come across this post today and it occurs to me that designing a project like this for lawyers is probably pretty challenging with git as the backend and I'm sure Jordan could use whatever the state of the art in VCS is. I hope they take a look at jj and consider it as an alternative backend. It seems there's an entire team of engineers working on jj at Google now full time.

Steve Klabnik wrote a beautiful book style tutorial[2] about getting started with it. Hopefully it inspires someone else to take a look!

[1]: https://v5.chriskrycho.com/essays/jj-init/

[2]: https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html

I'm just going to drop a casual shout-out to jujutsu[1]. It elegantly solves things like rebase/merge conflicts (and solves a lot of other sharp edges in git at the same time). It eliminates the need for WIP commits, stashing, and a host of other workflow bandaids we’ve all internalized. Best of all, it’s 100% git-compatible, so you can mix and match jj and git commands whenever needed, your coworkers never need know you're using something else, and even if it never gain critical mass you can still just use it and have superpowers while everyone else lives in the metaphorical stone age.

It is one of those rare birds that is both more powerful than the tool that it replaces while also being drastically easier to use. I am (was?) a git power user. It took me all of a day to replace git with jj and generously the rest of the week to become essentially as fluent. I will never go back.

Chris Krycho's post[2] was what originally sold me and I hope it sells you too.

[1] https://github.com/martinvonz/jj

[2] https://v5.chriskrycho.com/essays/jj-init/