In this episode of Brains & Beards, Patryk and Wojtek share why, after more than a decade with Git, they’ve switched their daily work to a new version control system called JJ (Jujutsu). They explain how JJ can sit on top of existing Git repositories, letting you use it even if your whole team stays on Git and GitHub, and why concepts like the operation log, easy undo/redo, and working with “changes” instead of “finished commits” feel much more natural to developers. The hosts walk through quality-of-life improvements such as effortlessly jumping between branches, editing old changes, splitting work cleanly, and avoiding painful tools like git stash and complex rebases. They also touch on the current limitations and dreams of a future “JJ hub”.
Our video about JJ: https://www.youtube.com/watch?v=J2f3Pj58wTg
Key Moments:
Introducing JJ (Jujutsu): The hosts explain what JJ is, where it came from, and how it works as a Git-compatible version control tool.
Why JJ works alongside Git: They highlight that JJ can be used on top of existing Git repositories, allowing silent adoption without requiring team-wide changes.
Undo/redo & operation log: A major selling point — JJ’s intuitive ability to undo any action and track every change, unlike Git’s cryptic reflog.
Working with changes, not commits: JJ’s model fits developers’ real workflow better, allowing editing of earlier changes, easy restructuring, and meaningful commit histories.
Goodbye git stash: JJ removes the need for stashing or temporary commits when switching context, making branch changes effortless.
MegaMerge capability: JJ allows temporary merging of multiple branches for testing without permanent commits — something Git can’t replicate cleanly.
Improved review workflow: JJ makes checking out others’ branches and cleaning up afterward much easier compared to Git’s messy local branch management.
Tools & ecosystem: Terminal UIs, graphical interfaces, and merge tools already support JJ, making it beginner-friendly.
Path to wider adoption: Discussion about the future potential of a “JJ hub” that works natively with change IDs.
Closing reflections: Both hosts emphasize that switching to JJ was easier and more valuable than expected — enough to inspire them to restart the podcast.
(Music)
(...)
Hello beautiful people, I'm Patrick. And I'm Voicier. And you are listening to Brains and Beards show. Episode number 21, why we stopped using Git. Enjoy.
(...)
Hello Patrick, how are you?
(...)
Hello Voitec. Fine, and you?
(...)
Well, I'm going through existential crisis.
(...)
Things that have been a staple in my life for a very long time are falling apart and collapsing like, I know like something that collapses very easily. See, I'm with a metaphor so I'm not going out well. So I've been watching the new season of the Witcher TV series.
(...)
And it's absolutely horrible.
(...)
It's,(...) of course, I'm going to still watch it because I'm a huge fan of the franchise.(...) But that's deeply disappointing. To be honest, I got this notification lately and I was wondering, oh, the show is still running.
(...)
Yeah, the show is still running, the actor changed, but like the actor doesn't really matter. The actor changed.
(...)
Now, they started off from a book that is already so big and so like rich in different things they can explore there. But they added some like, like they added their own things which are like from a cheap fantasy TV series.
(...)
Like it's not it's just like, you know, this there is this genre of TV movies that are movies that are not meant to go to cinema. They are like fit only for the TV and you have the general things. Oh, this is a Christmas romantic comedy. This is heist movie or so this is like a generic fantasy. It doesn't really matter who the characters are and what the whole franchise feels like.(...) Oh, here, let's do the episode where we do musical and dancing and singing. Sure, sounds like a great idea. Why not? And here it is. Okay. No, it's a bit bizarre. But the idea we're not here to rant about the how Netflix butchered the butcher of Blaviken. But we're going to talk about other existential crisis, how we stopped using Git, which was with us for, I know, 15 years, 18 years. Beautiful segue.
(...)
Well, thank you.(...) I prepared this is how much I prepared from the for the episode. The rest is complete straight from the heart. Okay.(...) I was thinking like because we ask, of course, we're going to record as well an episode about why we didn't explain it. Right. So why we stop using it like, okay, so what are we using right now? Actually, are we using our way back to SVN? Fortunately, not fortunately. Okay. So what are we using right now? JJ. So I see that you're dodging the most difficult part of the episode.(...) How do you pronounce the name of the tool that we use in the Git?
(...)
I will bite the bullet and pronounce that it's jujutsu. That's how my with my very limited Japanese. I can I assume it's meant to come from Japanese. Right. It's like jujutsu, but without the ISO. Yeah. Let's say jujutsu for once and then switch to the back end. JJ from now on like the comment on the common line.(...) So, yeah, I did the painful introduction of the name. Maybe you're going to introduce what the tool actually is and how it replaces get for us. JJ is to create it as a Google project by Martin von Zweigberg.(...) And now it's not anymore a Google project. It's not going to be sunset on anything. It's a full blown open source. I love the disclaimer. When you mentioned something is a Google project, you feel it's important to mention that even though it's a Google project, it doesn't mean it's going to be shut down. Of course.
(...)
But now it is a it's being developed by seven maintainers and about two hundred contributors. So it's like pretty big and they make sure that only I think free developers can be paid by the same company. So if there are more developers paid by the same company, they have to leave and be replaced by other maintainers. And this actually happened in September this year.(...) So, you know, they care about it. And I don't think he's going to be influenced by Google in some wrong ways. So what is JJ is like a version control system similar to Git. But it takes inspiration from Git Mercurial in some other version control systems. And therefore it's pretty pretty smart in the way how it works because they are standing on the shoulders of the Giants and they could learn from the mistakes and develop something much modern alternative to what we're using. So most of us are using every day like, you know, the kid was for SVN. SVN was as well like something cool to get came. This is what more or less JJ is in a nutshell. And this is what we use every day now since I think half a year.(...) I want to stress one thing because I'm not sure if it was clear to everybody, especially to somebody who's new to JJ,(...) that you don't you can work with JJ if the rest of the team works with Git because JJ is both like a way of storing information about the changes and a common line tool.
(...)
However, like I think in the long run, the idea is to that they have their own so-called back end, the way of storing the changes. But right now it's kind of Git powered. So you can use JJ on top of an existing Git repository and it's not like you're importing it. And later you were just working with JJ.(...) It still manipulates things and creates comments. So you can use JJ while the rest of your team uses Git and GitHub and nobody needs to know about it. Of course, everybody's going to know because it's like with veganism, CrossFit and VI, like on the first week, you're going to tell everybody, including your aunt and your aunt's cat that like you're now a JJ user. Like we're doing it right now, right?
(...)
But there is no conflict and you don't have to make your team switch to JJ. You can just silence the switch and see what happens. Yes. And even if you switch, you still can use Git in parallel. You don't know how to do something in JJ. You just run a Git command.(...) So, yeah, you can try it today without any disadvantages. It's not one of those technologies that you try and then you just start wishing you would be able to use it at work because you can use it at work. Nobody stops you from running your own command line. Well, I hope nobody stops you from running your own command line tools at work. Well, I don't know what happens if you work at GitHub.
(...)
That was as well like one of these questions where they perhaps shouldn't use JJ.
(...)
They shouldn't use work resources to work on JJ. Yeah, but like they can use JJ, I assume. There was this meme I know ages ago, like 15, 20 years ago, people were shocked that Microsoft developers are using Macbooks to run Windows because there was a moment in time where Macbook pros were actually one of the best laptops you could run Windows on.
(...)
So, like you would go to a Microsoft conference and like a lot of people would have Macbooks over there, but actually Macbooks running Windows.
(...)
I don't think they would ban you in GitHub. Maybe they are doing a JJ hub, like a spinoff silently. Yes, they do.(...) Perhaps not a GitHub, but some other companies are exactly doing this.
(...)
So, what else? Perhaps we should stress out that it's like not a big investment, as you said, to start with JJ. And actually, it's your one command away to try today in your own repository. Once you download JJ, I don't know, with Homebrew or whatever you are using for downloading the software, you're just writing "JJ" in it and you're done. So, you already have then JJ in your repository and you can use it parallel to Git. Okay, now that we've established that nothing actually stops you from trying JJ,(...) maybe let's talk a bit about why we actually switched. Like what convinced us to? Because until now we're talking that those are two ways of doing the same things.(...) And why would we prefer the JJ way instead of the Git way?(...) Why don't you give us a couple of reasons?(...) I understand everybody might have their own reasons and probably yours might be even different than mine. So, it's very subjective and personal what we're going to talk about here. But also, the main value is that a lot of developers seem to work with Git in a similar way.(...) So, what is subjective and personal for us might be actually equally subjective reason for you to switch. If you work with the Git like we did or like we do with JJ now.(...) So, Patrick, maybe tell us a bit about how you work with Git because you used to work with Git and how you work with JJ. And why did you bother to invest the time in switching over?(...) Personally, I like to learn new things.(...) So, that's not the best idea usually for choosing architecture or tools and so on. But I just love to experiment with new stuff.(...) So, once I heard about JJ, I just basically wanted to trade out. And this is what I did. And then I was trying to do in JJ the same things I was doing in Git. And of course that's possible. But then you see, okay, why should I change? There is no big difference if I can do the same in Git in JJ.
(...)
So, then I learned a little bit more about it and learned perhaps a new ways to look at your code and about the history of your changes. And then it make a click to me. And once I start to use these things which you cannot use in Git, then it basically I started to use JJ every day from this point on.
(...)
One question before we jumped into it. Did you use Git from command line or using some graphical user interfaces? The only thing I was using was I think lazy Git. It's like a terminal overlay for Git.
(...)
And that's all I think the rest I was all doing in the terminal. Just writing out the commands. And perhaps I was using for freeways merges, I was using p4merge. That's the only thing and nothing else. Okay. So, what made you switch? We can talk about the new ways of working in JJ. But I was thinking that the very first thing which is much better in JJ, and actually should be included in every program, is the ability to undo your mistakes in easy way. And you can do this in Git of course with now help me what was the command.(...) Git reflock, right? So,(...) you have to know this command and the name, it's not like very friendly name to do a simple job. And because you're going to make mistakes in your code and so on. And especially if you start learning a new tool, there are many commands which you're not really sure what they're going to do.(...) And if you don't have an easy way to explore, that's well have a possibility to go back. If you went the wrong path, then it's like really unfriendly way of working. Or maybe you're just going to start with a few basic commands and you're not never going to touch anything else because you don't know how they work. So what they did in JJ is they have operation log where everything is written like every commit you've done, every change to a file which is called a snapshot. So it's not only about the commands which are logged but as well like editing the file. If you change a line, it's going to be there.
(...)
And you could use this, but again this is like kind of operation log. Okay, it sounds a little bit more familiar than reflog. But still kind of cumbersome. So what they did is they added an undo.(...) And you basically if you do something you can just write undo and you are one step back. You can write undo again and then you can do it in a sequence as many times as you want. Going back and fixing your mistakes. And if you want to go forward, then of course there is a redo. And this is like super friendly because you're never going to forget that you have to write JJ undo because the undo is what everybody is using in every program and not something like reflog. Also, I wanted to comment one thing that the whole concept seems much more developer friendly here because with JJ you get the operation. It's an operations log and with Git it's a reference log. So it's a log of how references I think to head, how they changed over time. And the way I remember working with reflog in Git was that I was in my mind trying to think how far back I want to go.
(...)
And basically counting the amount of operations I did in my head to get the proper reference.(...) And with the JJ operations log, because it's a log of operations and not references, it's much easier to read. So even if you don't use JJ undo and you just look at the operations log, it's much more intuitive to work with it. So for me this was already a big plus point for JJ. The first time I had to undo some stuff that I messed up.
(...)
So even without the simpler comments, it's already a big step forward. Yes, but they have an operation log in the past. They gave just a wrapper for it with undo. And this is what they're doing a lot in JJ. They just want to be user friendly.
(...)
And this operation log as well contains what Git doesn't have is that the changes of the file, like changing of the line, adding new stuff to the file, it's going to be snapshot. Which is pretty cool as well when you're working with AI agents, which changed a lot of files. And if they make a mistake, you can go back very easily because everything is snapshot. And you can even see what they were doing. If you, I don't know, let them run for a few hours, then you can go back and see exactly what they were doing. Which is pretty cool, I guess. Yeah, and I think this last remark also brings us to the, I think, biggest difference between working with JJ and working with Git is that Git works in terms of comments, which are finished changes.(...) So you start typing your code and until you commit it, it's just a dirty tree. Like Git does not really care that much what you typed. It just, it knows you typed something, like something changed in the working tree, like you might want to commit it, but only like goes into action once you've committed it. And this is a finished change because of course you can rewrite comments, but you shouldn't be like this. The idea is like you wrote your code, you've finished, you commit this change, you move on to the next thing. And JJ does not really work with the idea of comments, but the idea of code changes, which is much more fitting for the way developers actually work. When you write the code, you don't really know if it's finished because you don't even know if it's working, right?(...) Like it's just a change in the code that you made and it has a name.
(...)
And JJ makes it very easy to remove it afterwards, move it somewhere else, expand on it.
(...)
And what's most critical is like you can go to an earlier change in your, in your like JJ repo, you edit an earlier change and it just like applies to everything on top of it, which in Git is complicated because you would have to, I know. Like of course it's doable, like you can create a new branch, edit the comment there and then rebase all the other comments on top of this one. And now, but now you're on a different branch. So maybe you should like reset hard the old branch with the new one to like, it's all doable, but you don't really have to do anything in JJ. You just do JJ edit, you put a change ID, you change stuff and then you go back to where you were before. And you have this thing changed like three, three comments down, which, which is great. In, in GIT, as you said, you can do always rebase, but that means that your commit ID is changed. And that's basically almost similar to showing a middle finger to your next developer who has to pull it in now. Yeah. In, in JJ, technically the commit IDs are going to change, but you work with change IDs often. So yeah, let's talk about the future in the future is, is going to be like this because in JJ, you have the change IDs, which never change. So if you edit a commit of some, somewhere deep in your history, it's still gonna have the exactly the same change ID.
(...)
And so if the next developer are gonna pull this branch, let's say, then there's, you know, like they're gonna have the same change IDs. There is no gonna be a mess of, of something changed completely the tree. But it's, you know, the trees are exactly the same after your change.(...) There is a slight problem because right now we have to push the most of the changes to the GitHub. And of course, GitHub works with commit IDs and not with change IDs. So that's the problem. But in the future, once we have something like JJ hub,(...) this is gonna be a cool new way of working. If you are a developer who just make one commit per branch, you know, like I implemented the thing and you pushed, I don't know, 35 changes into it, then JJ is not gonna make you any difference. It's not gonna give you anything like it's gonna be exactly the same as in Git. But if you like to have small commits, which somebody can separately, you know, read and see how, how you develop the implementation. And move around. Then JJ is much easier way to, to achieve this because as you said, as you said, you never know at the beginning how you're gonna develop something. Usually I have to try out many ways. And I picked the one which I liked. And I liked my history to be green with meaningful messages inside. Right. And this is like cumbersome in Git. I like the concept that I gave up on. On the small, on the small commits. Small meaningful commits were and people not rewriting history with like merging stuff back and forth. Yeah.(...) Well, I think it's always easy. That's true. But sometimes, you know, you can do it and it's a much nicer experience to do it in JJ. That's for sure. Sure. One more thing that like also comes with the difference. Probably there's going to be more things that come with the difference between focusing on comments and focusing on code changes is that if you're working with a get and you made a change in some branch and you want to check out something else. What do you do? For me, there are two strategies. Well, there are two strategies I used. And sometimes I prefer one. Sometimes I prefer the other. If I think I'll be back on my branch within 15 minutes,(...) I would just git stash my changes and remember for 15 minutes that I need to go back to this branch and unstash it. But it's something that I have to actively keep in my mind. Which branch do I go back to and that I have stashed changes there. So it's valid for something that I know will take 15 minutes. If I think I will not, I might not be back to this branch soon. I would make a comment, call it like work in progress and then go to the other branch, do the thing, come back and then I would probably reset this comment. So now it's a dirty tree again so I can work on those changes. It's a hassle. And with JJ, you don't really have to think about which strategy you use because these are all code changes. You just switch to a different branch.(...) Maybe if you think that you might forget what you were doing, you just do JJ describe and give a name to the change that you're leaving behind so that it's easier to go back to it. Because the describing a change is not like a commit message. This is the final thing I did in this comment and now it's written in stone and so on. It's a commit hash and whatever.(...) No, it's just a description of the changes that are contained under this ID. So I think for me this was like a big quality of life change. I liked it much more. I liked it much more with JJ. Now gitstache just sucks. There's no way around it. It's just bad. It's a just growing list of things you wanted to do. You forgot it just grows and then you can make a mistake and instead of apply, you pop it and that's what you wanted to say if there is gone.
(...)
I was going to mention that there are ambiguity between the pop and apply. It's just bad. So yeah, the way of branching out or putting new changes to exactly the places you want to in JJ is just super easy. Just JJ knew and you pick from where you want to branch out and then it's done. I mean, super easy. And the other changes are staying in the place where you left them. Couldn't be easier.
(...)
Also, there's a related thing there that I noticed actually after switching. I noticed that when I was reviewing other people's code, it was a bit annoying that they have like a PR on GitHub and I would read the code on GitHub because I don't really want to switch to check out their branch locally because later I have to manually remove this branch.(...) But maybe I'm going to check it out again. So should I remove it now or should I remove it after it gets merged? And basically what I ended up doing is I was using the GitHub UI as much as I can. And if I had to run the changes, I would only then I would check out the branch and once every few weeks, I would list all the branches that I have locally.(...) I would dig up the old command. How do you delete all branches that they don't have a fresh comment on them or they don't have a matching branch on origin. So like they're only local, they've been deleted on origin.(...) And so it was just like a maintenance I had to do. It was just annoying as I know, switching tires on the car. Like, you know, you have to do it, but there's no join it whatsoever. And with JJ, the thing goes away because I'm just making a new change on top of somebody's branch.(...) And usually I don't make any actual code changes there. I'm just like reading and running the code and so on. But if I do add some like console logs, play with it and so on, then I just do JJ abandon and that's it. The whole change disappears. Because, you know, like you mentioned, okay, you can always read it on GitHub, but you cannot test it there very easily.(...) And what you can do with JJ, even if you don't like it, there is a concept of MegaMerch, which is basically in JJ, you can have a commit which merges multiple branches together without merging them like permanently.
(...)
And this means like you can check the PR check the newest main and check perhaps your changes in one place at the same time.(...) And you can always update one of those branches via one simple command. So you can always retest it and retest it with the newest changes from any of the branches, basically. And this cannot be replicated in git basically. Yeah, no, no, go on. I was wondering why it can be replicated. But you cannot say, okay, you cannot replicate it because in git you would have to merge it permanently. Basically, you would need to merge one branch.
(...)
You would have to do a commit with a merge and then you would have to do another commit doing the same merge the second time. Yes. And then is how do you update one of those branches, you would have to, I don't know, rebase and then merge again,(...) where, you know, like on JJ, it's very easy to absorb the commands into the branches and then without moving the commit which integrate them all together. So that's why I'm thinking we don't have anything like that in git. Quick side note, because especially right now, I wish I had the demonstration for like, how does it look in practice.(...) And here on the podcast, we're talking about how we feel about JJ what we find interesting there. But we're not going to give you an intro on how to work with it. And obviously, you're not going to see any code, right? It's an audio only form. But if you're interested and you want to see how Patrick guides you through different exciting JJ features should check out our YouTube channel. Brain pegs. Brain pegs. If you put brains and beers brain pegs, you'll for sure find it. I will link it in insights, the podcast. Sure. Yeah, we can link it in the show notes. So if you're interested and you want to see more hands on experience, how does it look in practice working with JJ? I do it personally a lot of times. When I don't bother to check out one code tool myself, I would just rather watch a YouTube video for 20 minutes of somebody doing it for me while washing the dishes. And after that, most of the time I would like, I'm fine. I'm not like gonna do it. So yeah, if you're like me, maybe it would be best to to also check out Patrick's video. We would be very happy to see you there. The recording is more about concepts, but hands on. And later on, we're going to have new episodes where we can describe basics like how you can start with it. How the day to day work would look like in JJ. So you can get some inspirations. As I said at the beginning, I was trying to use Git inside of JJ instead of using the new ways of working. So perhaps you can, we can give you like a little bit head start and you would start with new practices. Yeah, I think that would be great because that's the exact trap I fell into myself. When I felt a rebase is an answer to my problem. Trying to translate the rebase flow from Git into JJ was particularly cumbersome for me. And usually it ended up with doing something else that solves my problem much easier than a rebase would. It just, I did not know what it is at the time. Just digging into why I cannot just rebase this thing over there. I learned something new about like JJ that helped me solve my issue. And yeah, in the beginning I was actually, when I got stuck, I was just making sure I have Git comments and switching to the magic in Git and then go back to JJ and work from there. This happened, especially in the first couple of months. And I was just thinking like about this.(...) So sometimes it is hard to start on implementation because the task is so big that it can be overwhelming.
(...)
And there is like a mind trick which you can use as well in JJ, which is not available in Git, that you can start with an empty change and give it a name. Like you write description here, I'm trying to move this function to a new file and then you start working on it. Where in Git is this is impossible because you would have to start to do it and then give it a name with a commit, right?(...) And this mind trick sometimes, you know, like unlocks me when I'm feeling stuck and I don't know what to do. Just starting with writing, you know, plain English here. I'm doing this. And then once I've done this, sometimes I can just follow up with code changes much easier. And then you have nice commit history because you already started with a description what should go inside of this change. Also, another is such a small tip that I was very happy with is with Git to have smaller comments and also to review my the stuff that I'm committing. A lot of times I would I was doing interactive adder. So it was going like change by change, like not actually line by line, but like by groups of lines asking, do I really want to commit this?(...) And this was annoying because we're like, hey, here's the change. Do you want it in or out? And you make a decision, yes or no?(...) And once if you have a long change and you pushed the wrong button at the end, the way to fix it for me would be to reset the change and go through adding everything again and make making sure I give the right answers.
(...)
Or sometimes you will see a console lock there. So you will like exit it, go back in and so on. It was annoying process, but like it did what needed to be done. And with JJ, I would just do JJ split and I would split things into two changes. One is that stuff that is ready. And this is a more interactive thing you can like mark and select and unselect every single line or every single change. You can do it by file. So like it's a pretty nice interface where you can like look through it and make decisions as you go. And you can go back to the previous decisions and make them and so on. And basically I use JJ split to split the things into what I want to commit and what I still am working with. Or I would I know I would just like those are the console lock leftovers. I would just abandon them. And another thing on top, git add the interactive one works for adding, but JJ split works as well for splitting like past commits. So you can pick a past commit,(...) split it into and the funny thing is even that the commit you split it out from has exactly the same change ID, didn't change. The one which was above him in the past didn't change changed ID and the new commit goes in between. So you split it commits without changing the change IDs of the repository, which is pretty cool. Yeah, I think like it all comes from this like paradigm shift where you work with code changes rather than finished comments.(...) So that helps developers do a lot of things that in a more natural way. And I only need the JJ hub to exist. Because for now it's this what we are talking about is mostly a local experience and it gets a little bit destroyed once you pushed those changes to git hub and then you pull them back. I mean, JJ is fine with it, of course, but but in that case, some commits gets immutable,(...) and you cannot change them easily. And you have to pass some flags to do it, but then you have to force push and so on. But you know, like there are people actively working on on some place for us to store the code inside of JJ. Oh, that's that's great news. I personally I don't like my experience with using JJ locally and pushing to get up to work with the rest of the team has been surprisingly smooth.
(...)
And I definitely it's better than when I was using get like by itself. And I feel it could be improved with the whole team use JJ and we would have some kind of JJ hub that operates on change IDs. But it's not bad. Like it's, I think it's still an improvement over the git flow with the with GitHub still nicer. And most cases, there's anyway, that's what you push it stays in your branch. And mostly you are using that alone. I think the worst case is when when you have some automatic things which, which are pushing commits on top of your PR, because then you have to pull them and they are not. They haven't been in JJ in the past. And I think there is a little bit more manual stuff you have to do when you work with those changes.(...) But yeah, you shouldn't have any problems. Just try today and and be happy with it. Cool. Yeah, that sounds like good advice.(...) Actually, that's how I that's advice that got me into JJ in the first place. I was just scrolling randomly through blue sky. And I came across some a couple of developers that that I respect.(...) They were saying, Oh, like, oh, there was some something about giddels and somebody mentioned that, Oh, I've been using JJ and it solves this problem. And it's I'm very happy with it. And the other guy says, Yeah, yeah, I've been using JJ for a year and never going back. Like, it's sure like this is solved like the I could see the discussion of both of them that they agree that this tool is clearly superior to the common line git experience. I was like, Okay, like it's very rare thing for two developers to agree on anything. So that's what made me take a look.(...) And yeah, and the tool made me stay. And actually, I was I was worried there's not enough value there to actually make the switch. But actually, but the switch was easier than I expected. And the value is higher than it was was higher than I expected. So I'm very happy I did. And if you need some some tools around it, because you don't like the writing, writing out those commands,(...) there are, I think at least five terminal based tools for JJ,(...) and at least two graphical user interfaces for it. And it is being supported as well in some some other programs for conflicts related to the resolution and so on, like kaleidoscope and melt and other things. So yeah, if you don't like the command line, you don't need it, you can still use JJ without the command line. Yeah, but I think if you're using git without the command line, I think you're already limited to a subset of it. I'm not sure how much of value you're gonna see if you switch between a graphic using a graphical client for git and graphic client for JJ.
(...)
Well, I know I haven't I haven't been I haven't used much of the graphical UI for git.(...) Anyway, maybe, maybe. I mean, that's how to say,(...) okay.
(...)
Drop us an email if you do if you switch and see the improvements or you don't let us know. That would be cool. We would gladly read it. Okay, I think that's all for today. That was kind of a long one, I think.(...) I thought this is gonna be quicker.(...) But yeah, it was I hope it was interesting to you. I hope we could convince some of you to try it out. And if you want to know as well, what is what is missing in JJ, like,
(...)
maybe there are some things why you shouldn't change because you're gonna miss some important things, then next episode is gonna be exactly about this. Yeah, that's gonna be the episode where we poop on it.(...) From all the possible angles you can find.(...) Exactly. Not that many. But yeah, exactly. And this, the next episode is much shorter.(...) So it's now it's scientifically scientifically proven that there is more goodness than badness inside of JJ. JJ is 50% better than worse. Yes.
(...)
Okay, was nice talking to you, right? Yeah, I missed this on our podcast break.(...) It was great to to get the ball rolling again. Yeah. So expect more episodes from us. Thanks. You can thank JJ that it brought us back. True. Podcasts are magical. True.
(...)
I look forward to the next episode.(...) Me too. See you. Bye bye. See you. Ciao.
(...)
Thank you for listening to the episode. Please subscribe if you haven't yet. And if you like our show, consider sharing it with your friends. You will find notes to this episode on our page, brainsandbeards.com slash podcast, where you can as well give us feedback or suggest a topic for the future episodes. We would be very happy hearing back from you. Stay safe and curious. Till the next one.
(...)
Hey,
(...)
(Upbeat Music)
(...)
(Upbeat Music)