What if version control was AWESOME?

An introduction to the Jujutsu Version Control system!
• Jujutsu VCS: github.com/martinvonz/jj
• jj init essay: v5.chriskrycho.com/essays/jj-...
• gg UI for jj: github.com/gulbanana/gg
• gg intro video: • GG demo - Jujutsu GUI
• Tauri: tauri.app
• Git: git-scm.com
• Mercurial: www.mercurial-scm.org
• Distributed version control: en.wikipedia.org/wiki/Distrib...
• SVN: subversion.apache.org
• CVS: cvs.nongnu.org
• PVCS: en.wikipedia.org/wiki/PVCS
• scm-diff-editor: github.com/arxanas/git-branch...
Find me elsewhere online:
• www.chriskrycho.com
• bsky.app/profile/chriskrycho.com
• mastodon.social/@chriskrycho
• / chriskrycho
• / chriskrycho
Chapters:
0:00 Introduction and background
0:49 Distributed version control background
2:57 What is Jujutsu?
5:27 The gg GUI for jj
5:58 Git interop and basic Jujutsu usage
9:08 A first commit
9:57 More than a nice UI for Git
11:09 A standalone Jujutsu repo
12:38 Working with Jujutsu
14:40 Change evolution (obslog)
17:31 jj undo 🫨
18:40 Making changes and jj split
20:15 jj new, jj describe, and jj commit
22:13 Changing earlier commits
23:43 Conflicts 🤯
28:21 Jujutsu is cool 😎

[@bernardcrnkovic3769]

the fact that it interoperates with git two-way is a big win in my book. good job whoever is working on this 👍 but honestly i dont see myself using it since git is just so simple and well integrated everywhere i dont feel a need to optimize its workflow further.

[@ChrisKrycho]

I totally hear that! I suggest giving it a try-you might find yourself thinking “Wait, since it interoperates with Git I _can_ just use this everywhere…”

[@Jonas-Seiler]

@@ChrisKrycho can you really use it everywhere? mainly my concern is how well jj still let's you work together with people who aren't sold on jj already, that is, people who continue to use git. surely there must be some caveats when pushing and pulling from purely git based remotes, right?

[@ChrisKrycho]

You really can! If you are using the Git backend (and everyone outside Google, where there is a non-Git backend, is using the Git backend) it ultimately really is creating Git commits, branches, etc. It is possible there are issues I have not heard of or run into, but in practice… it really does just work! I have been using it (including at my previous employer and for open source contributions) on Git repos for many months now and have not hit any issues at all.

[@rh4009]

@@ChrisKrychoSince a conflict is "first-class" (great feature, btw), what happens if you push a conflict to github, for someone else to resolve? This might happen if you have to do a hairy (conflicting) merge from a team mate. You might need to push a partially resolved merge conflict for someone else (with pertinent expertise) to resolve the rest. It's about time the idea that "conflicts are normal, not taboo" took hold, and that is what will make jj a better tool than git, not the little neat convenience features, which are great but not sufficient. How does jj implement collaboration on conflict resolution?

[@ChrisKrycho]

@rh4009 that’s a great question. Details of collaboration using the native jj features are still being worked out. For today, the guidance would be: don’t push a conflict! Resolve it before you push. If/when we get “forges” with built-in support for Jujutsu, this will be one of the things it should support for sure!

[@armynyus9123]

30 years in IT and kept Mercurial up to the very end, against all resistance. With git, well, back to xkcd 1597 -> will definitely try jj, many thanks!

[@margue27]

Same here, we are still using Mercurial in my team, and no intention to change that.

[@simonmassey8850]

wow. the approach of adding a better workflow over the git storage model is something that i must try out.

[@Dominik-K]

Thanks a bunch for the intro to jujutsu. Has been really helpful to see how to use it

[@lunakid12]

JJ looks very cool, thanks for the great intro! (A side note: please don't force 60 fps on us for nothing.)

[@FryGuy1013]

Over the years I've been pretty sad that git won the DVCS war. I loved bazaar. It was so simple and straightforward, and the verbs and nouns made sense. This looks neat.

[@rid9]

This sounds like Schrödinger's VCS: observing the repository's state changes it.

[@ChrisKrycho]

Kind of, yeah, @rid9! The key things which make that safe, though-and this really took me a while to wrap my head around-are that (1) *every* operation happens on the repo rather than on “commits” or diffs, unlike in Git, and (2) every operation is _safe_ because you can always undo. You can even undo a `jj status` and restore to a previous version before the snapshot happens, which is fascinating!

[@rid9]

@@ChrisKrycho indeed, that sounds very interesting. I don't think there's any other VCS that works quite like this. They made the undo history or the local history you see in IDEs like IDEA and, more recently, VSCode, a VCS concept. It would probably be even more useful if they could create these snapshots on a regular basis instead of waiting for the user, which could be too late.

[@ChrisKrycho]

@rid9 Yeah, the maintainers have talked about some of that. There’s already a watchman integration, so you could imagine having something which builds on top of that and just auto-snapshots any time you save a file, or at least any time you add or remove a file. I haven't felt the need of that so far, but it could be cool. You could also do it yourself fairly easily using something like watchexec.github.io - `watchexec -w . jj status > /dev/null` would do it (and there might even be a way to explicitly ask for a snapshot via CLI, but I have never poked to see what it is if so!).

[@garcialn]

I loved the content. Always though git is unnecessarily complicated for modern days (obviously is incredibly useful and necessary for any project). i'm amazed to see a nice approach to the problem that still can work WITH git, to use in any past, present or future project... Gonna start using now and hopeful for more content on it. Thank you for sharing it :)

[@EvoMRI]

This walk-through was an unexpected delight - thanks! Kind of reminded me of the way LyX interacts with LaTeX. While I've stuck with the original there, Jujutsu seems well worth a closer look.

[@peterszarvas94]

a conflict of conflicts, omg... maybe it's a good thing that git freaks out when you have a conflict

[@ChrisKrycho]

😂 In this case it was purely because of the specific way I hand edited through it with a text editor. That would have been equally nasty (if not more!) in Git. I just need to use the diff tool instead next time, but I didn’t want to muck with that here. Tradeoffs!

[@mrtnhwtt]

Really cool video, it made me want to try jj!

[@BradArnst]

Interesting. Thank you for bringing this to my attention.

[@gotoastal]

Nice to hear the Pijul callout (tho it’s pronounce pee-hool for a bird name in Spanish) but there was not a history mention for Darcs which is still being developed & has had a lot of these features for a really like time. Personally I find the Git interop to be a something that may shackle the project to Git’s design choice than actually help, & the fact that Google is involved to a degree leads me to distrust it. Long live Darcs & good luck Pijul.

[@ChrisKrycho]

This was apparently the video for me to learn about _all_ of my VCS mispronunciations! 😂 Thank you for that info-I will remember it. One reason I am not worried about it being shackled to Git’s design choices is that there is already a Google backend which is _not_ Git, as well as the “native” backend, which is not production-ready by any stretch but which they require every feature implemented against Git to support. I think it will work out in much the same way that Git could interoperate with SVN back in the day, but was not overly coupled to it.

[@AlfW]

Good luck pijul? I'm not a pijul user tbh but from all what I've read and heard about it, I'd say it's already "better" than darcs, or like a more modern and faster darcs.

[@bassamalharbi7108]

Thank you, I like it. I will give it a try definitely

[@pqnet84]

If it can do rebases without using the checked out working tree sounds like a win. Performance is something else that is worth considering: is the automatic rebase that happens when you change an old commit something that I can stop thinking about or do I need to be careful of what happens when I do that? For example, what is there is a daemon looking at the working copy and recompiling/restarting the app being debugged it every time a file changes, will it be triggered by jj doing rebases behind the scene?

[@ChrisKrycho]

I imagine if you were editing a point sufficiently far back in a very large history, it could become _something_ of an issue, but in general you wouldn’t do that unless you were doing something like removing a secret from the repo history: once something is in whatever your “trunk” branch is, it’s bad form to edit it-and Jujutsu helps with that by making those commits immutable by default. I did actually rewrite some history in a way that changed a few thousand commits once a few months ago, though, and that was basically instantaneous.

[@jhuyt-]

The thing that seems worth switching for is the ability to ignore conflicts, but it's not clear how that would help since I'd presumably have to run the code and code with conflicts is typically an syntax error. Is there something there I'm misunderstanding? Beyond that, is there any benefit yo using this over plain git if the workflow is git add -> git commit -> git push -> merge and squash on GH? That covers 99.9% of what I do with git professionally and it's hard to tell from this demo if jj is an improvement in this workflow. Also I'd suggest using a bigger font size for the code, it's very tiny and kinda hard to read, especially on mobile devices.

[@ChrisKrycho]

I will get into this a bunch more on the next video, but the thing first-class conflicts helps with a _ton_ is things like rebasing. When you do an interactive rebase in Git, you have to fix every conflict before you move on. When you do a rebase in Jujutsu… you do _not_ have to. It materializes the commits as part of the change graph, and if there is more than one distinct commit, it materializes them _individually_. That means you can deal with them individually. Another thing that isn’t obvious from this video (because of the specific nature of the example I chose) is that it can carry that resolution forward automatically-kind of like `git rerere`, but in my experience much more effective. On the code size-yeah, you’re definitely right! I thought I had made it big enough (you should see how small I work with normally!) but I wasn’t accounting for YT compression and watching this on _way_ smaller screens than my nice 2560×1440 retina monitor. Whoops!

[@Reecepbcups]

cool! trying it out for my weekend project!

[@ChrisKrycho]

If you run into any bumps, the community and development Discord is great! The developers are all in there and happy to answer questions and super receptive to feedback.

[@L0wPressure]

I did not know i needed it, until i saw this video :)

[@OverWilliam]

Everything you *said* sounded great :) Wish I could have followed along visually. Too small to read. But I had a lot of fun imagining what the terminal interface COULD have looked like!

[@ChrisKrycho]

Yep, you’re not the first to say as much! I’ll be on a smaller resolution and with much bigger fonts next time!

[@apina4]

To be fair, was just fine on fullscreen video

[@garcialn]

If your watching on phone, you also can zoom in to understand better from the text ;)

[@yash1152]

3:10 have u tried "fossil" vcs? i'd like to see a comparison between some of these. i was really leaning on towards the fossil before i encountered the jj, branchless-git, git-town, etc etc

[@ChrisKrycho]

I have! I really like it. I find Jujutsu fits my brain better, though, and the fact that it interoperates cleanly with Git makes it way easier to adopt.

[@banzooiebooie]

What is the name of the gorgeous font in your terminal?

[@ChrisKrycho]

It’s the so-very-excellent Berkeley Mono! berkeleygraphics.com/typefaces/berkeley-mono/

[@JeffHeon]

I’m just happy undo isn’t something I have to lookup every time that’s called git reset blabla. Also that I can use restore instead of rm’ing a repo and doing clone again because I fudged it so bad (yeah I don’t want to lookup another reset command 😅)

[@karpfenboy]

looks useful and i will try it since its sitting just on top of git (i do alot of rebase -i and add -p so this might save a bunch of steps)

[@gotoastal]

a lot*

[@IgnatRemizov]

How do branch merges look? Do I preserve branch history?

[@ChrisKrycho]

Yep! I will show more of this (a _lot_ more!) in the next video, but they are basically everything you get from Git with merges… and a lot of other niceties, too.

[@reverse4646]

Thank you for sharing, didnt know jj before. Currently I am happy with fossil scm, it is used for the sqlite codebase and can export to git too. I always like learning about "better/newer" source code management approaches.

[@ChrisKrycho]

Fossil is also super cool!

[@kellymoses8566]

Version control that is syntax aware would be so powerful.

[@Jonas-Seiler]

What exactly do you mean by that?

[@BLUYES422]

im just trying to figure out how to move main up to my current rev in jujutsu. it seems great but every time i want to update my git branch with my changes i feel like im pulling teeth

[@ChrisKrycho]

Ah, that one took a little to internalize, yep. You do `jj branch set main` if you’re still on the revision, or `jj branch set main -r @-` if you have done `jj new` or similar. There is also an experimental feature to advance branches automatically, which may be stabilized in a future release (you can use it now, though). I found I pretty quickly stopped worrying about that, though; I just update the branch with `jj branch set` when I am actually ready to push.

[@IgorKaratayev]

sadly no submodule support that jj desc feature is kinda cool. I was working on a git plugin which stores every file change in a git branch - thus providing a persistent undo/redo feature. something what can be easily done with jj describe.

[@ChrisKrycho]

It’s true that submodule support _per se_ is not there today. I don’t know if the devs are going to add direct support for Git submodules, though I wouldn’t be surprised, but that workflow need is one they are well aware of in any case. They will definitely be solving for that problem, even if in a different way from Git’s approach.

[@AnalogIdeas]

Is this a way to make Git sane like Mercurial?

[@ChrisKrycho]

Among other things, yes!

[@Jonas-Seiler]

I was not convinced jj was doing much of anything differently at first, but towards the end I started to think “wait a minute, this IS pretty cool!”, however I am not so sure if that’s a good thing. To me this gives off 2 major foot gun vibes, one setting yourself up for ever more painful conflicts the more you defer resolving them, the other making it harder to actually track source versions by allowing you to insert changes everywhere, and I haven’t even thought about potential issues in terms of collaboration. How is this all solved? Or why may this actually not be a big concern?

[@ChrisKrycho]

That’s a great pair of questions. On the conflict, this was really just a case where I picked a bad example _and_ resolved it in a silly way (using a plain text editor). In general, Jujutsu has _fewer_ conflicts than Git does, and the experience I showed here where resolving one ends up causing further conflicts down the line is really rare. What’s more, when you use a regular diff editor tool instead of doing it inline in the text editor, it would be a lot easier! But one upside of Jujutsu’s model is: when a cascade _does_ happen, you can just steadily resolve it downstream, rather than having to abandon your rebase (or whatever) and try again. A couple things help with the concern about collaboration: 1. Just like in Git, it is relatively rare to have multiple people working on the same branch at the same time. When you do, you need to coordinate. However, Jujutsu actually makes that kind of coordination _easier_ because it understands merges and conflicts much more rigorously. 2. Jujutsu has a built-in (but configurable!) notion of “immutable heads”, that is, things you’re not allowed to change. By default that is any tags which exist and whatever your “trunk” branch is (main, master, etc.), but you can configure it as you like. You could make it “anything which has been pushed to a remote” if you wanted, and that could be a good fit for a lot of collaboration models. Notably, that is _more_ capable and powerful than what Git offers, where Git servers have to configure that, and it is not set on a per-repo level.

[@Jonas-Seiler]

@@ChrisKrycho I see how your last point does answer my question in regards to collaboration, even if the remote didn't use jj. It's easy to see that in that regard jj will even at the absolute worst be at least just as good as git. I'm willing to believe jj is probably just a straight upgrade, but I'm not yet fully convinced. Just gotta see how the near future turns out first.

[@timseguine2]

I like what I see, but I do think it looks like it might be easier to get yourself into situations where in git you would have to use reflog. But then again, seems like if you do that you can just undo.

[@sheevys]

What about darcs and pijul?

[@ChrisKrycho]

Both super interesting as well! Pijul’s rigor is particularly neat. I find Jujutsu to be a bit more of a “fit” for my brain than either, though.

[@arisweedler4703]

Great demonstration of some of jj’s capabilities. First time hearing of it. Adding “C++ is to C as jj is to git” - you can use a C++ compiler on C, you can use jj on a git repo. Because jj is like this I can and will start playing with it next Monday Ok, so why am I interested in jj now? Because it centers the developer over the data. You can write a “commit message” (you can describe your changes) before you write a commit. You don’t have to resolve conflicts immediately or have everything just get wonky

[@antonurvantsev2913]

Wait a second, isn't jj a kind of continuation of ideas introduced in gerrit? Gerrit is used at google and it introduces the concept of "Change". Each change has its own change-id and it's own "story" of states represented as patch-sets and so on, and so forth...

[@ChrisKrycho]

Some of the ideas are definitely shared with tools like Gerrit and Phabricator, but lots of VCS systems-most notably Mercurial!-have the distinction between change and revision ID.

[@9SMTM6]

What I'm looking for from a new VCS is being better able to work with generated files or binaries. And obviously being able to match git for the things it's great at. I'm not sure that that is a solvable problem. But that'd be great. Using gut with stuff like games is very much possible, but it relies a lot on conventions and discipline, and can easily go wrong.

[@tigertiger6376]

Thanks for the vid. I still love Mercurial so much, the rise of git has made me sad. Will check out jj.

[@mattiamarchesini3387]

I think git was the only really fisable source version control system for too much time now, maybe it is time for innovation, jj being this innovation or not.

[@ChrisKrycho]

Yeah, Mercurial was also feasible in a lot of places for a while, but the social dominance of Git via GitHub and GitLab in particular really made it hard unless you were a big company. Notably, both Google and Facebook/Meta have made use of Mercurial, though! I definitely agree that it’s time for a successor.

[@xorlop]

@@ChrisKrycho I wanted mercurial to win so bad when I tried it out. Jujutsu seems really cool. I am eager to try this out.

[@vrjb100]

Sscs was the first version control I used, yes I'm that old. Merge conflicts are the punishment for bad design. Version control should not solve this problem. Working in the same file for realizing a feature is bad organization of work. Sscs made it impossible to work in the same file by multiple people at the same time.

[@karpfenboy]

@@vrjb100 i disagree, i don't think files should map the relationship of how people collaborate. Neither should the architecture of a system be influenced by it

[@ChrisKrycho]

Having worked in systems like that myself (PVCS was my first VCS! And I worked with SCCS as well), I deeply disagree. With enough people working on sufficiently large or interesting projects, coordination about who is _allowed_ to work on a given file can drag things to a crawl completely needlessly. Merging and resolving any conflicts is a pain sometimes but I will take it over the alternative!

[@movax20h]

Nice. I always (last 13 years) hated git rebases and conflict resolution, and lack of notion of change set. jj definitively is something I will give a try. It remaind me of some workflows when working at Google. Unfortunately jj is not in Debian repos, nor Fedora, nor Centos, nor precompiled arm binaries (Arch and FreeBSD apparently do have them in their repos). Also interface, is not as nice I would like it. It is a bit of a chaos with all the colors. Like who needs these precise dates of each change or commit, or timezones. It is a bit noisy, but for sure could be rectified.

[@ChrisKrycho]

Yeah, it is still pretty early, so distros do not have it yet-I wouldn’t be surprised if they get there in the next year or so, though. The interface for logging is _very_ customizable-it is a whole little functional language!-and has a really nice templating language (much easier to use than Git’s!).

[@grproteus]

I don't get why the commit message needs to be an input variable. Why not keep it in a separate file, which can also be editable? It would make life easier both for the jj developers and for their users.

[@ChrisKrycho]

No doubt you _could_ do something like that (though you would need to be pretty careful about it in terms of editor buffers not getting updated and overwriting it with the wrong thing), but in my experience with PVCS, CVS, SVN, Mercurial, Git, and now Jujutsu, not one of them has used that as the normal way of working!

[@algot34]

text is too small on my monitor

[@ChrisKrycho]

Thanks for the feedback! And yeah, several folks have pointed this out! I will be recording the next one at 1080p (but retina!) instead of 2560×1440, which should help, and I will make the terminal and editor way bigger, too. (You should see how small I _normally_ make them: this is already blown way up!)

[@To1ne]

Good video, but I'm not sold yet. But magit has been solving most of these Git issues for me.

[@RasmusSchultz]

It's interesting, for sure - some nice improvements over Git, no doubt. But you know how every language these days has a language service that plugs into your editor/IDE of choice? The next level source control system I've been dreaming of actually integrates with your editor/IDE in real-time - it tracks and records every keystroke and change that you make, and it integrates changes from different peers using Operational Transformation. If you don't know what that is, it's the algorithm that makes Google Docs possible. Imagine you would never see another merge conflict. 😄 Of course, you might not get working code after a merge, but that's the limitation with any distributed source control system - a successful merge does not guarantee working, correct or meaningful code, that's just a fact of life. But the chore of manually merging text, oh man, I would give anything to be rid of that. 😄 Now that would be next level. Not that this isn't cool - it looks great, but it might not be quite enough to tip the scales where everyone switches from git. For that, we would need something revolutionary, not just a value add. Again, it does look like a nice value add though! 🙂👍

[@dazealex]

Subbed. git is fine, but too overly complicated and heavy when it shouldn't be, esepecially for people like me who don't use it every day. This seems interesting!

[@kayakMike1000]

You're in the right ball park. We don't NEED another system. A standard interface (maybe a DSL like SQL) would be great.

[@mike200017]

Interesting. After using Git and Mercurial for some years, then using Piper for many years, I've come to the conclusion that the only sane way to use Git is to only create branches off of main, make small changes and immediately merge them back. Never branch off of other branches, never rebase or anything like that. It seems like because Git was designed to be really powerful (if you can use it, but I've never met anyone who can) at handling complicated graphs of branches and commit histories, people are way too quick to make a mess of it. It seems that JJ is moving more in the direction of Piper, that is, favoring a stack of changes on top of a base version. I wonder if JJ makes re-syncing easier too? I hate the git nonsense of pulling main and merging it into branches. Git really encourages long running branches off of old revisions of other branches, when for any decent sized project, you need to stay up to date and merge frequently. I've always thought that a good metric for the usability of a version control system is how often you end up resorting to good old diff-patch. With Git, I have long since given up on attempting any sort of branch surgery if I get into any kind of trouble. I just get a diff off of a known good state (e.g., main branch), then edit the diff file to add, remove, split the changes how I want, and then patch those diffs back onto clean new branches.

[@kartonrad]

Dont you ever... just merge? It honestly works every time You just resolve the conflicts And the end result is miraculously actually executable

[@kayakMike1000]

Well... There's certain programs that are on the edge of easy and hard. Its worst place to be as a program. Easy enough for everyone to program a eeasonable solution, but hard enough to please everyone

[@md2perpe]

I know the guy who wrote this, Martin von Zweigbergk. We went to the same church when he lived in Stockholm.

[@loftyTHEOWNER]

When I do "jj git init --git-repo ." and then "jj branch track main@origin", everything works but if I do "jj log" I only see the history up to the last git commit, which is different from your output. What did I do wrong?

[@ChrisKrycho]

Ah, this is a good question! jj defaults to showing you only “interesting” commits, but if you pass `-r "all()"` it will show you everything. I will dig into the reasons why in a future video!

[@watcherquek263]

Hmmm no comment about Microsoft Visual Source Safe and Teams Foundation Version control? ;)

[@ChrisKrycho]

😂 I have, to my lasting joy, never been subjected to either. I did have a close encounter with the IBM Rational system at one point, though.

[@SourceOfViews]

Honestly, I don't see the value. Git's CLI could use a makeover and I have made quite a few aliases and extra commands for convenience, so I'm happy about some reinvention, but I don't see it here. Let me address some points in detail: 14:40 I'm not sure what the addition of changes accomplishes. I quite like that git only has two first class citizens: commits and references. That means that in every command, you can use any kind of reference interchangeably however you want to. Doesn't matter if it's a branch, tag, stash or relative reference (HEAD), I can use any of them with any of the others and it work exactly as expected. Adding another first class citizen to it, needs to add a lot of value and I'm not sure changes do that. What you showed in this video, I don't find particularly exciting since in the rare case I need it without having expected it, I can use reflog. It's a bit messier, but it works well enough for how rarely I need it and with a bit of filtering magic, you can get the same result. What WOULD excite me is if it also creates a commit every time I restore or delete a file. I have a few times accidentally removed a change like that, that I'd've liked to keep. So having that is nice, especially for beginners. I haven't seen it in this demo, but I assume it works like that? Otherwise, I usually just create a bunch of temporary commits and rebase once I got something working. 19:10 The split is convenient, but it's essentially just git reset and then followed by the two commits. It's more typing, but it also allows for more flexibility without learning another command. Want to split parts of the same file? commit -p Want to completely remove a change? restore Want to make three files? simply commit three times. You can just re-use the same commands you use for creating commits already. I wish git had better support for splitting with git rebase, but all I want there is basically a way to retain the original commit message ^^ 20:15 Not sure why you'd splitting commiting. I never had an idea for a commit message before I actually made that commit. And if I want to I can still just simply make a temporary commit and amend/rebase later. It's again a bit more complicated, but I also rarely ever need that. 25:10 Git is absolutely fine with this? It doesn't stop you from adding a file with conflict markers, it will simply treat that as normal text. And looking at jj it seems to do the same thing. The only difference I could see here is that git immediately interrupts the operation (merge or rebase) and asks you to resolve it while jj only tells you once you are on a commit that has a conflict in its history. Well and I guess that with git you might forget about it easier once you commit a file with change markers, which is fair, I guess. Personally, I almost always want to immediately resolve a merge error though, so I want to know asap. I don't think I ever felt like first doing something else, honestly, so I'd rather by default have it prompt me to resolve it. All in all, I see how this might be easier for beginners, but I fail to see a good value increase once you have mastered both of them. I'm not sure that a master of jj has an improved workflow over a master of git and ultimately that's what it will need for me to consider switching. The git interop is great and definitely needed if it wants any chance at being adopted. Similar as what git did for svn, I suppose.

[@ChrisKrycho]

Thank you for the thoughtfully-detailed reply! I do not have time to dig into all of it this evening, but will try to get back to it tomorrow if someone else doesn’t reply with details first. A couple quick hits, though: 1. Multiple times here you say something to the effect of “this is a bit more typing in git, but…” or “this is a bit harder in git, but…”-I think it is easy to underrate just how big a difference it makes for _every_ part of working with your version control system to be just a bit easier. I was skeptical along the same lines, and working with Jujutsu for a few months made working in Git feel actively _bad_ now by contrast. 2. On a bunch of these things, I will be digging into them in future videos-already planned to hit them, in fact! This first one was intentionally a very high level overview, because when I wrote a 10,000-word behemoth of an essay on it… one the main pieces of feedback I got was that people wanted to see more examples of the basics of what it was like to just use it. 3. On committing conflicts specifically: there is a big difference between just committing conflict markers (and hoping you realize it later) and the VCS tool itself *_actually understanding the conflicts_*. They’re represented as textual markers, but Jujutsu actually knows about them in a deep way which lets it propagate fixes to them automatically. Think the best parts of `git rerere`, but… way better, in a way I will show in one of the next couple vides. There is also some good material on that in Steve Klabnik’s tutorial (steveklabnik.github.io/jujutsu-tutorial/) as well as the docs (martinvonz.github.io/jj/v0.15.1/) and the FAQs (martinvonz.github.io/jj/v0.15.1/FAQ/). Like I said, I really appreciate this kind of detailed comment, and I will try to answer in more detail on those specific questions tomorrow!

[@VioletJewel1729]

6:16 - that's as far as I could make it. You almost sold me on this. Your terminal is illegible. I'm coding on the side and the window takes up a little more than half of my screen, and I can barely read anything. Please increase the font size. Also, I can't believe you use a light background in your terminal, but to each their own.

[@ChrisKrycho]

Yeah, another commenter noted the same. Sorry about that! I will probably switch my effective resolution to 1080p (but Retina) for the next one, which will also help a lot, and also just make everything _even bigger_! I forgot how much the YT compression plus a smaller screen than the source can really muck with it.

[@VioletJewel1729]

@@ChrisKrycho I did sit down and watch it while eating. It's interestin. Lookin forward to more vids

[@kayakMike1000]

Uhhhhhh. git is awesome.

[@ChrisKrycho]

It is! That doesn’t mean we cannot improve on it, though!

[@kinjalbasu1999]

jujutsu is pronounced "Joo-Joo-tsu"

[@ChrisKrycho]

So I have learned! We will see if I remember every time I say it in the future. I also expect a lot of people will say it with the schwa sound though!