Hey, everyone, welcome to the Unhandled exception podcast. I'm Dan Clark and this is episode
number 64 and that means we've hit another power of two with the episode numbers. And
this episode is all about Git cracking, which I'm a huge fan of Git. I've used lots of
guillies throughout the years and I've recently started using Git cracking a lot more. And
it's a very cool Git client. And I'm pleased to be joined on the show today by Justin Roberts
and Eric Amodio from the Git cracking team. So welcome, Justin Eric to the show. Could you
both give yourselves a quick intro to the listeners and just tell us a bit about what you do.
You wanna go first, Eric? Sure. I'm Eric Amodio. I've been in DevTools for a while. I worked on
the VS Code team, worked on Git extension on VS Code and a bunch of other things there, VS Code
Dev. And now, yeah, CTO Git cracking, that also created GitLens, which is a very popular IDE
extension for VS Code. So yeah, happy to be here. Thanks for having me. Yeah, and I'm Justin Roberts.
I am a senior director of product here at Git cracking. I started my life more in the design side of
software. So mostly UI design and kind of some front end development and started at Axosoft,
which was the original name of our company right before we started working on Git cracking,
actually. So we used to build kind of project management tools in the Jira sphere and we lost
to Jira ultimately, but luckily, we kind of pivoted and started building Git cracking. So I've been
on that project pretty much since I've been at the company. And it's been really fun to kind of
start in the design side and go all the way up through kind of guiding it as a product.
As you find that interesting, quite a lot of companies do that and they start with one direction
and pivot and make a really successful business. What was the, there's a famous one, I completely
forgot which company it was, which not YouTube, something similar to that Instagram, that was it.
Yeah, there's been a few of them because like Slack started that way, right? They were starting to like
build a game or something and this talking was on the side.
Cool. So before we start talking about Git cracking, I'm just going to do this episodes list
to mention. And this one goes out to Richard Whitfield on Twitter. I need to eat his mentioning
episode 59, where I was joined by Valentina Stupak chatting about hexagonal architecture. And he
tweeted, love this episode, both excellent and well communicated knowledge from Valentina and
interviewing masterclass from Dan. Great work, both. So I was kind of like interviewing masterclass.
I'm not sure that's quite true, but thank you for Richard for saying so. It certainly means a lot.
And back in episode 58 with Nick Chapsas, where we were talking about his dome chain platform,
Nick gave me a few 100% off coupon codes to give away my docker course, which is on his
platform. And he suggested giving that away for listener mentions. So congratulations, Richard.
A docker course is coming your way. And if anyone else wants to get mentioned on the show,
just send a social media post about the podcast app mentioning me on any of the socials.
And all feedback is greatly appreciated.
And don't forget that this podcast has its own discord community.
If you head over to the website, unhandledexceptionpodcast.com,
you'll see a big shiny discord link there.
Edited Dan here just to quickly add that the Git cracking team have very kindly offered a
Git cracking license to one of the listeners.
If you're interested in being included in the raffle, then send a LinkedIn or Twitter post
about both the podcast and Git cracking app mentioning me so I know about it.
And I'll put one at random in a few weeks time.
So back to the show.
Right, we can now get on with talking about Git, which I'm a huge fan of Git.
I've been really looking forward to this.
And I think it'd be quite interesting to hit this from different angles.
So the listeners are obviously developers, so we can talk about Git cracking as a product.
But I think it would also be interesting to talk about your experiences developing a Git client.
I think that'd be quite interesting.
I guess let's start with it as a product.
And I'm going to start with a big open question here.
If I were a developer looking for a Git client, why should I pick Git cracking?
I mean, that's a great question.
I mean, I think that we are, even as far as I can tell,
probably the company that is investing the most time and energy into continuously refining
what a Git client should be.
Right, a lot of the other Git clients that are out there, there are some exceptions, I think,
but mostly they're just kind of like off to the side.
They're not anyone's main priority.
They're just kind of like table stakes for having a Git client.
And they just kind of have basic functionality.
And we really put a lot of effort into kind of refining the user experience
and making Git easier to use, not just simply exposing the functions of Git in an interface.
Yeah, I kind of, in preparation for this episode, I kind of did a mental list
or what I say mental, I've actually written it down, a list of things I like
and things I don't like about it.
And you'd be glad to know the list I like is a lot bigger.
And I can certainly talk about my experiences because I've used Git for many, many years.
But I've only recently, I did use Git cracking.
I tried it years ago and I didn't stay using it.
I can talk about why if you want, but I've recently picked it up again
and it stuck this time.
So I've been using it for a few months now.
I really like it.
And I think one of the reasons is the fact that it integrates so well with other stuff.
So I use Azure DevOps, but also like GitHub as well.
And the fact that pull requests, I can create them, I can jump to them,
I can see information about them.
Because I'm not using the cloud workspaces.
I don't feel I'm getting all the functionality that I'm sure you get if a team uses the cloud version.
And yeah, I'd be good to talk about that as well.
But yeah, just being able to create them and jump to them from the client is really good.
And there's a bunch of stuff, I suppose.
We could go through the different things that I personally have stood out,
which makes me want to stay with Git cracking.
Or we can talk about the different high level features like these workspaces
or I actually recently watched your, what was it called?
I didn't make enough to peek into the Palantir.
I think that's the Lord of the Rings reference.
Yeah.
Git cracking's vision to the future developer experience.
That was a good video.
Oh, thanks.
Yeah, we, I mean, Git cracking has seen a lot of evolution since we started it.
We started in back in 2015 and our core premise was basically just make a Git client that doesn't suck.
Right.
Because we were constantly running into issues onboarding developers on to Git.
We had Windows devs and Linux devs and Mac devs and everyone had to use a different client.
You know, there was Source Tree and there was Git extensions and there was Tortis Git.
And some people use the command line.
So I just remember that the onboarding for even devs in our organization was really intense around Git.
We had these three hour long videos that we recorded on like how to get your system set up to use Git.
And it was just like this painful experience that led to like, why isn't there a better client out there?
Like, why is this so hard for us to get everyone onboard on to Git?
And right around that time, it was kind of like an inflection point where all of these technologies were coming together that helped us to be able to make a product that was cross platform really easily.
Electron had only been out for a year or two.
GitHub was making the Adam editor, which we all really liked using.
So there was a good example of like kind of a broadly used product that was based on Electron.
React had just become stable in 2015.
VS Code came out later in 2015.
So there's all of these things that were kind of coming together.
They're like, OK, like, we could make a cross platform Git client based on all of these kind of like web based tools to make something that has a really nice user experience.
And anyone that's on Linux or Mac or Windows could use it really easily.
And that was kind of like the core premise when we started.
And, you know, it's just a matter of timing, right?
Like no one else had done this in the way that we were doing.
And it just kind of took off from the beginning, even when we didn't have feature parity.
So there was just something to be said about creating a better user experience,
even if it wasn't completely in parity with other Git clients or other Git tools
that I think people are looking for, just some way to be able to intuitively understand what was happening in the repositories and interact with them.
I think also, it's kind of, this shouldn't matter as much as it probably does,
but it really looks good as in aesthetically, one client I've used for years is SmartGit.
And the functionality is amazing, it's really, really good, but it looks so outdated.
And it's weird, it shouldn't matter.
It shouldn't, but...
Having a nice shiny GUI does make a big difference to me.
I mean, people like things that look nice, things that feel good, things that work.
And if you're going to be using a tool every day, yes, it has to be functional,
but I think that extra level of UI and UX polish goes a long way.
And it's funny, when we made Git Kraken, we were the only Git client that had a dark mode.
And for developer tools, it was just kind of blatantly obvious,
like why wouldn't you have a dark mode?
And I think, honestly, we got a lot of traction just because we had a dark mode in the beginning,
again, even when we didn't have the functionality there to match other products.
That's something too that's been common across Git Kraken and GitLens,
is just really to try to amp up the user experience to really focus on the design of it,
make sure that it's really easy to use, intuitive as best you can.
And yeah, I think that is a really important aspect.
Props to Justin, Justin was involved very heavily
at the beginning of Git Kraken and designed a lot of the UI.
So yeah, it's been a great road there.
Yeah, anything without dark mode is a deal breaker for me.
So it's kind of...
All my windows now in dark mode,
and if a minute team's call and the product tone or something shares the screen,
and it's like Jera in light mode, and it's like, ah, I've been blinded.
Yeah, I get that all the time when I switch to a Google Doc or something
and that doesn't have dark.
It's like, oh my God, I can't see.
I think another thing, it's kind of like, I know a lot of IDs,
like Visual Studio, RIDO, or whatever you use, have Git integration.
RIDO's Git integration is absolutely amazing,
but there's something to be said for having a dedicated app for it.
I actually like being able to...
In some senses, when I'm actually in the zoning rider,
I like being able to just commit there and then and not have to switch to another app.
But in another, I actually like having a dedicated full GUI that is designed for Git.
Especially because sometimes I'm doing stuff in VS Code,
sometimes I'm doing stuff in RIDO.
It really depends on what I'm doing.
So I actually like having a dedicated application for that, really.
Yeah, it's interesting.
GitLens is the most popular Git extension for VS Code
and has a lot of that functionality in it.
And recently, as GitLens has joined GitKracken,
we've been trying to bring some of that kind of Git GUI functionality into VS Code
by taking the graph that we built for the GitKracken client,
putting it into GitLens,
to try to find where that line is,
where devs like to stay in an IDE
and what they like to do in an IDE
and what they like to do in a GUI.
And it's been interesting watching who likes to use those,
who wants to use the visualized graph inside of an IDE
and who prefers to switch to a client.
And there's just varying degrees of who's willing to do what
in which client or which type of environment.
And I mean, the bottom line is everyone has all their preferences
and it's really hard to say,
this is the one way to do it.
I think also, if I think about me personally,
I don't have one particular preference,
it depends on what mood I'm in.
So sometimes I'll just do it in the IDE where I am.
Sometimes I'll switch to a terminal
and just do it in the command line.
Sometimes I'll switch to GitKracken.
So it kind of like,
that's the thing I like about Git actually,
whichever one of these you use,
it still get under the hood,
so it doesn't matter, you can hot swap between them.
So I think that's quite powerful.
Jumping between the Agoui and the CLI,
I'm someone, I live in the IDE,
but I do a lot of commands on the command line
and I switch back and forth depending on what I'm doing.
And yeah, just being able to just work with the underlying
Git structure, visualize it when you need it,
switch to the CLI when it's more convenient
and back and forth is definitely very valuable.
And it's something too that even from the beginning,
I use, Tortis was the client that I used the most
at the beginning because I could still do stuff,
mean stuff on the command line
and I did a bunch of work too with the PoshGit.
So it's a lot of enhancements to Git just in PowerShell
and just being able to do most of the commands there,
but then just, hey, if I wanted to do a log of history
or I wanted to see what commits I had,
I can just pop up a Tortis Git window
right from the command line, do what I wanted to do,
click, okay, and then I'm back to the command line.
And just that interaction also led a lot of the combinations
to building out GitLens to make it easy to flip between the two.
And the Gitcrackin client is doing the same
with the integrated terminal
and to try to be able to slip between both of them
depending on your mode of working.
It's not all gooey all the time or all CLI all the time, right?
It's this good mix in between
for depending on what you're trying to get done.
Early in the days of developing the client,
we were so focused on making a good gooey
that we actually had marketing campaigns
that were gooey versus the terminal
and why the gooey is better.
And it's been interesting to see how our thinking has evolved
to who cares where you use Git.
We can help you understand Git
and interact with it better in any surface.
And we just recently released a completely standalone CLI program
that tries to do a lot of the things that we have in the client
of interacting with workspaces
and being able to visualize your pull requests
and issues inside of a terminal.
And if that's where you prefer to work,
well, then that's fine, go do that work there.
And it's been a cool journey to grow
to just saying anywhere we can help devs work with Git.
It doesn't matter if it's a gooey or in an IDE
or in a terminal or in a web browser,
we want to explore any possible way
that we can help devs use Git.
Yeah, that's kind of like one of our mantras
of meeting the developers where they are.
So, if it's in the IDE, we're covered there.
If it's on the desktop, we're covered there.
CLI, we're there.
We want to do it on the web.
We're launching Qcrack and Dev on the web to bring that there.
So, I mean, we're trying to just sort of provide the tools
and continuity on wherever you work.
And an individual dev may switch between those modes
or someone may work in only one
and we'll just be there to provide really good tooling
to improve the productivity collaboration
across the board.
Well, I mentioned before about,
I really like the pull request integration,
but because I'm not using cloud workspaces,
I'm probably only using a small feature set.
If I'm using Gitcracken
and I'm in a team that does PRs and does this kind of stuff,
but I'm the only one using Gitcracken,
can I still leverage that or am I limited?
Well, I know the video we mentioned before, you showed off.
The Gitcracken focus view,
and you could see across lots of repos,
all the PR statuses,
you could pin them, you could snooze them,
which look quite cool.
Can I actually leverage this
if the entire team hasn't bought into Gitcracken?
Yeah, it's still a productivity feature for individual devs.
From the beginning, we wanted to be
not only cross-platform on whichever system you work on,
but also like Git hosting agnostic, right?
We didn't want to pick one tool and say,
like, we're only for GitHub or we're only for GitLab.
So, making sure that we have integrations
to all of these hosting services,
not only for Git, but also for issues,
has meant that our mindset has evolved to saying,
like, it's not just Git and writing Git commands,
it's pull requests.
It's the issues that lead to opening a branch
that lead to a pull request
and trying to find ways to weave
all of those systems into one workflow.
And the focus view and cloud workspaces
are just kind of the next evolution of that thinking.
If you're already connected to these services
and you're pulling in information about pull requests,
what can we do in all of our tools
to help you focus on the issues, the PRs,
the branches that you have open
that are most important to you,
that are most critical for you to kind of get done?
And that's what the focus view is trying to do,
is pull those all into one place
and just give you a single prioritized list
of, this is the most important thing for me today
and tomorrow and next week
so that you can kind of burn those down
and use the integrations on all of our products
to kind of follow on what's next
and take the next step on getting that PR merged
and that feature out.
So at the moment I just use,
so I've created a bunch,
cause I'm a contractor so I've got different clients,
I've created a bunch of different workspaces and profiles
which is a really cool feature, I really like that.
I like the fact that profiles,
the authentication with each of these integrations
is per profile so I can switch over between clients.
I think that's really nice.
But I've only been creating local workspaces.
If I was to create a cloud one,
if I did that against a client
so I could see pull request off,
is that focus for you in my client
or is it going off to some Gitcrack server
that is like mediating it to some website or something?
It's just connecting you to the services
that you have integrated.
So it's going out to GitHub or Jira
or the integrations that you have connected
and then pulling the data in
and then showing that view to you.
On my machine.
Yeah, in that UI.
So we're just going and fetching data
about your pull requests and your issues.
So when you create that cloud workspace,
the only thing that we're storing
is like the references to where we go get the information
and then we're just sending that to your client.
So any authentication stuff is staying on my machine?
Yeah, yeah, and the client today, yes.
Yeah, for the CLI and for GitLens
and we're starting to move more authentication
to the cloud to enable a lot of other features.
But yeah, I think there will probably be a mix
of you'll be able to authenticate the cloud
to take advantage of a whole bunch of other features
or just do local authentication.
Yeah, and the Gitcrack and server is sort of involved
for just storing the metadata
about the workspace, which repositories are in it.
And then if you're using pinning and snoozing,
those are, you know, we're storing data
about sort of like a unique ID
that we generate for the particular issue
or PR that you pinned or snoozed.
And then that's the data we're storing about that
so we can bring that back into that view.
That's really cool.
I feel I, whilst I'm enjoying Gitcrack
and I feel I'm not leveraging
half the functionality I could be doing.
So I feel like tomorrow I'm gonna do that be,
oh, no, I've got to take the kids to football,
but I'll find some time tomorrow
to try to play and server can set this up.
But it does that.
As I say, watching that video
where you were showing off like this focus for you
and being able to snooze stuff and focus stuff,
that looks so, so powerful.
So I'm looking forward to playing with that.
I'll have to persuade the rest of the team
to get onto Gitcrack.
Yeah, and we're pretty early into that development.
So any feedback, anyone that is using these
and find something that's like,
oh, it'd be really nice if it did this
or if I could connect to this.
We're listening really carefully
to a lot of that feedback coming in now
to try to hone them into the most valuable
kind of features that we can offer.
Yeah, cause we're just, yeah.
Thanks, Justin, mention we're just getting started on that.
You know, the vision for that focus view,
like we really want to evolve it
into much more of an assistant
to help you prioritize things most effectively.
We have very rudimentary ranking in the view today
and we're expanding that out
and what things are most important to you.
If we can go and look, it's,
hey, there's this really small PR,
just needs a quick review.
It's attached to a high priority issue, right?
Like make sure that that's up there, get the review
or there's a PR that's already just waiting,
just needs someone to click the merge button.
Make sure that that item is sitting at the top of the list
with a nice merge button, one click done
and you don't have to leave and jump to any hosting service
to make that happen.
So really just trying to really bring things together
but really focus on giving you,
you know, prioritization of what things that,
you know, you should focus on to really increase your,
you know, time to merge
and productivity for your whole team.
So can I filter it and say,
only show me really easy PRs?
Don't show me anything complicated.
Not yet.
We do have, we do have a PR complexity.
We added a PR complexity kind of status.
It's only for GitHub right now,
but what we try to do is take in a bunch of factors
and use some like heuristic system to say,
like this is a really complex PR.
So you might want to like get on it early
or make sure that the right people are involved.
Anything that we can do when we're connected to
your hosting integrations or your issue integrations
to help you hone in on the things that are one,
most important or to like have a higher risk
of potentially getting delayed.
You know, that's what we're trying to explore now
is how can we really surface that stuff
where before you have to bounce around, right?
You have to jump to GitHub,
you have to jump to Jira
and you're kind of juggling all of the states
of these different things.
And the idea behind what we're doing
with the focus view is like putting it all into one place
so you can just like process it and say,
all right, what's, what's at risk?
What's going to take a long time?
What can I just knock out really quickly?
So you joke, but that's something that we've talked about
is like if there's just something easy that I can knock out,
can I just go do that right now
while I'm waiting for a build or something
and just get it done?
Yeah, we definitely want to turn that into,
even just like medium gives you a time to read.
This is like giving you a rough estimate of a time
by, as we learn more and get more of this data
of seeing how long it takes for these reviews,
we can start providing better accurate estimates
on what these things would look like.
And we also want to take the concept of nudging.
Like doesn't necessarily have to be like notifications
or notifications are in your face,
but just little things that just sort of guide you
to the next steps or,
or like if a PR has this high complexity,
well, we might want to nudge the author of like,
hey, this is pretty complex.
Why don't you break it down
or provide a much better description
that helps somebody go through the steps of like,
how you're setting this up,
provide better descriptions that sort of thing.
So just these sort of nudges that can come
in an automated fashion
or even from other users
to provide better communication and collaboration
around those things.
Also just going back to the actual client itself,
like the log view,
one thing I like,
so I quite often am involved
helping people less experienced in git.
Like say, like if they struggle with like a rebase
or something, that kind of thing.
And I quite like, even though most of the time
I'm a keyboard shortcut person
and tries to reach for the mouse as little as possible.
One feature I do like,
which is a mouse feature,
is the fact that you can like drag the branch tag
in the log
and you can drag it onto another branch
and then you get like a right click context menu
automatically
and you can choose to like fast forward merge
or rebase or whatever.
And I feel like when explaining that
and showing that,
the people that are new to the concept of rebasing
and stuff,
just taking that and dragging it on top
of another branch
that kind of helps them visualize a bit better.
I think that's quite nice.
It's interesting when I was talking earlier
about like our whole onboarding to git in the company.
I remember specifically one of the videos
that we showed to everyone
to try to like onboard them to git.
Was someone describing branching with like tinker toys?
So they had like this physical tinker toy model
that they would build
and they're like, okay, we're gonna bring a branch
and now we're gonna like take that branch
and we're gonna rebase it on top.
And there's just something intuitive about
like, I mean, they were in the physical realm
moving things,
but like the dragging and dropping,
the like contextual,
like I'm taking this thing
and I'm moving it on top of this thing
that helps, I think,
make those concepts click for people.
And that was really the goal
behind putting a lot of effort into that graph,
making that kind of visual,
not just look good
and organize the information,
but when it's interactable
and you can drag
and then just see like,
what can I do in git
with these two branches
that are related to one another
and get a list of options?
It uncovers a lot of what's possible in git
that you would normally have to go hunting for.
Like, I want to try to do this thing.
What's the command to do that?
I do wish there was a,
I don't know whether it's
class of the bug or a missing thing,
but if I do that drag
and if I do it with a different branch,
then I can choose fast forward merge.
But if I do it like, say, main to origin main,
fast forward merge is missing from the drop down,
which I think I like quite often,
I would feel that if I have my hand on the mouse,
I would like to do that fast forward.
Otherwise, I've got to right click
and say fast forward merge,
but I'd like to drag it up almost.
I can't remember though,
I've reported a whole bunch
of little suggestions and things.
So I might have already done that one, I don't know.
Yeah, I mean, I think that's how we got connected
with one another, right?
You had a suggestion to us,
maybe on Twitter, that something wasn't as accessible
as it could be or keyboard manageable
and that started the conversation.
And I don't know if anyone's updated you,
but we are in our release that's coming out next week,
improving some of the things that you had suggested
and just being able to navigate between panels
inside of the client with the keyboard.
So thanks for that suggestion.
We do, and we have always been really interested
in listening to what customers and users say.
We all have Twitter threads in our Slack channels
that we follow, so we know what people are talking about.
We have a feature, a vote, a board for suggesting features
that we look at very frequently,
just to get a pulse on what the users are saying
that they really want.
And we do our best.
Obviously, it's not possible to do everything,
but we try to find the things that we can have
the biggest impact on
from what our users are saying
that they'd like to see in the client.
So, I appreciate that feedback.
Yeah, no worries, no worries.
I had quite a good chat with Jeremy.
And so I shared my screen and showed him
like the gaps I found.
And I think this goes back to before when I said that
I tried it many years ago, and then I just didn't stick.
And I think it's because of,
there was a lot of missing keyboard shortcuts
and watching quite a few of the tutorial videos.
You can tell that people doing the tutorials
is very mouse oriented
the way they're clicking through and everything.
And it just felt like there was,
there was just a few extra shortcuts
that would have bridged that gap.
There was just a few little frustrations.
And you know, I jumped on the call with Jeremy,
showed him kind of like where the gaps I found were.
And I just don't think there were a bit,
I think there's just a few extra hotkeys, to be honest.
So yeah, it's awesome that that's coming so quickly.
Yeah, it's a challenge, I think,
just accessibility in general,
especially when you start a product
that didn't have that as one of its primary goals, right?
Like we kind of went really fast on this kind of UI focused GUI.
And we were so focused on the UI
and the clicking and dragging
that like we just didn't spend time on keyboard navigation.
So it's a challenge to try to catch back up to that.
Because when you build a system that isn't kind of
expecting to do that by default,
it's harder to do that.
But counteract that or counterbalance that with
GitLens and VS Code,
which is something that is like,
I don't know Eric if it was designed
from the ground up to be keyboard accessible,
but I know that that's a really big focus for them now
is just making sure you can do everything with the keyboard.
Yeah, maybe we could be a keyboard accessibility
as it was kind of baked in early,
even just further than just keyboard accessibility
in general for screen readers
and that sort of stuff was,
it's been a thing at Microsoft for a while,
but you know, and so it was in that purview.
But over the last at least two, three years,
it's been a really strong focus of VS Code
is to really spend a lot of time on true accessibility
from contrast to screen readers,
to all that sort of support
that they've done a lot over the last couple years
to improve that.
And so we take advantage of a bunch of that
because we're in that space in GitLens.
So it just becomes easy to play well in there.
But then there's, you know, our own web views,
the graph still is not at the level of accessible
that we would like.
And we're just continuing to improve that.
One thing is as we start building out these newer features
or bringing these features across the product,
accessibility is one of the priorities for us.
We want to make sure things can be used
by the biggest group of people,
again, meeting the dev where they are.
So as we build out these new components
and stuff in the client, in GitLens, in the web,
we're really baking that in from the get go
which makes things a lot easier to continue
to improve upon.
But just keyboard access in general
is something that we're going to be spending
more and more time on
to make sure that you can really easily navigate
to getting to the actions that you're looking for.
Yeah, that makes quite a big difference.
And as I say, it just feels like
there was a few little gaps.
There wasn't, there is keyboard shortcut support.
So moving on to, we spoke about the two different angles,
like one as a product and one, what's it like to develop.
I'm curious, also with Git,
one topic that comes up quite a lot
is the different Git branching strategies.
So there's lots of different ones.
I'm just curious too,
you develop a Git client,
what strategy have you landed on
with developing Gitcracken?
I think we have a couple across our products.
I know the client specifically,
the strategy that we've used since the beginning,
and I'm sure that this has kind of evolved
because I don't hear as many people using it,
is that we operate with forks.
So everyone has an individual fork of the main repo
and they kind of work on those separate forks.
And then when they're ready to merge into the main remote,
they PR into the main.
So we have like everyone
with all of their different forks of the program.
And so when you want to go check out someone else's branch,
you have to have all of their remotes,
which I think is sort of the opposite
of the trunk based development
where everyone just works off of main,
which I think that's probably how GitLens works, right?
Yeah, we're trunk based, committing to main
is the normal mode.
And we have shortly of PRs for specific things
to make sure that sort of thing.
And then we have nightly builds
that go out to users every night
to get feedback and pre-release.
So yeah, it's definitely different cycles
on how that is.
And yeah, it's also easier, right?
As teams are smaller,
that is a lot easier to manage.
I mean, they still can,
VS Code for a very long time
was trunk based development as well.
And only over the last year or so,
they switched to a strong where devs
can't commit directly to main everything
that goes through a PR.
So it's been an interesting change
to see and watch.
But yeah, there's lots of strategies there.
But it's funny, ages ago,
lots of things were all trunk based
because branches were super expensive.
And then Git came out
and some of the others,
Mercurial and Bazaar and a bunch of these others
were making sort of the branching strategy
basically free.
And then it sort of proliferated
in branches for everything.
But then we find that it's challenging too.
You get these long live things,
you get branches that never get merged back in.
It gets more and more challenging.
And it feels like getting to really short PRs
on a trunk based is coming around again
as much more productive
just because you can move much more quickly
and you don't have long live things
that you're constantly trying to merge
or rebase to keep up to date with the main.
But that's still definitely a challenge
on how things stack on one another
and all that sort of thing.
Those are also areas
that we're looking into heavily
of how we can play well in that scenario,
how those things work together
to bring that together to make it easier.
Yeah, that's definitely a strategy
I kind of taken,
like trunk based development
with short PR branches.
And then I think when you're doing
trunk based development,
if you've got good test coverage,
that makes a huge difference
that you can safely just deploy just main
and then have that deploy be released
as long as you've got good test coverage
and feature toggles and things.
Out of interest,
I know you're talking about GitLens.
Does GitKracken have like pre-release versions?
Not yet,
but we're trying to follow
and GitLens' footsteps.
We have internal development
and staging builds
and we're trying to refine
our build system
so that it's easier for us
to do more frequent early releases
and get feedback earlier in the cycle.
Right now, we usually do a major release,
I mean a larger release once a month,
but it would be really nice
to get down to once a week
and then once a day,
just like GitLens does,
to get that feedback earlier.
I suppose that was one of my observations,
I think.
Since I started using it,
I think there's only been one update.
I thought it was,
I've been using it longer than two months,
so I thought maybe I've had two,
I don't know and I didn't spot it.
It does feel that that would be more useful
having like,
because I've submitted a whole bunch
of bugs and feature requests
and just having that faster cycle
and turnaround,
which it sounds like
that's what you're aiming for,
which is quite cool.
I know one tool I use
to do this,
to do this.
A couple of times a day,
I see just a little red dot
in the top corner
saying there's a new version,
restart if you want to update.
And so they're doing it
literally all the time.
And I think that's just such a nice
flow where you know you're getting
frequent fixes and things.
Yeah, and having a pre-release
or an opt-in way to do that
is one of the main reasons
why we don't release more often
with the client,
because it's a 100 megabyte
or whatever download
and we don't want to just be pushing
that on everyone every day
if they don't want to
eat up their internet traffic
that often.
So definitely getting to a mode
or a version of the client
that could allow people
to opt into that
is really what we want to get to
before we start pushing releases
out every day.
Yeah, that makes sense.
I'll opt into that when it's out.
OK.

I'll go for the nightly builds,
live on the edge.
Definitely.
That's my dev tools
are all living on the edge there.
But yeah, I mean,
I think one of the things
that we're looking forward to
is just not only just testing out
our experiments,
but just, yeah,
you could turn around fixes
or turn around attempted fixes.
That's something that is just
the great feedback.
Gillens is open source.
We have a strong community
of bugs coming in and feedback
and we try to be as active
as we can on issues getting filed
to go out and try tomorrow's release.
Did it fix it?
And we get really good engagement
on that.
It's great for the community,
but it's also great for the product.
We can sort of address things
really quickly,
get them out,
get them tested,
and everyone sort of benefits
from that tight feedback loop.
So that's one of the best things
about working on an open source project
is just that feedback loop
is really rich.
I mean, we want to bring that
into Gitcrackin
and our other tools
as much as possible.
Feedback is crucial.
So making Gitcrackin open source?
That's probably not going to happen, but...
I thought you said that somehow.
But just being able to report
with the feature upload,
with just community,
we have a community Slack
where you can report things there
just trying to improve upon
the feedback loops
and the speed at which
that those feedback loops
can be closed.
So if something gets reported
from Twitter, Slack,
wherever,
we can turn around and say,
oh, well, hey, try that out
in the next day
or in a short period of time
that's not in a full long cycle.
That's really cool.
I didn't realise you had a Slack,
actually, so I'll jump on that.
I think you mentioned earlier
about integration issues,
like tickets and stuff.
I use Azure DevOps
and I couldn't see when I went
to the issues drop down
that there was,
in fact, I've got it here, actually,
in Gitcrackin.
And it's got a list of all
the integrations,
but it's not got Azure DevOps in there.
I can use whole requests,
but just not issues.
That should be working.
Are you on cloud
or self-hosted Azure?
Cloud, so Azure DevOps Cloud.
So if I go to my pull requests,
oh, is it related to the workspace I've got?
So I've got a local workspace
even though I'm connecting to...
No, you should be able to switch.
Actually, you know what?
The Azure issues
might only be working with cloud
workspaces right now.
It might not be available
as a standalone issue tracker
inside of the client yet.
Fair enough.
Fair enough.
I was just wondering,
because I think I saw on the website
as well that it mentioned
issues support for Azure DevOps.
So I guess that's the cloud one.
But yeah, from our conversation,
it does sound like
I could easily switch over
even if it's just me using it.
That does sound good.
I'm trying to think what else
we've not covered.
I'm just like,
as I mentioned before,
where I created a list of things
I really like.
One of the things I quite like
is like this solo view as well,
which is quite nice.
Just being able to say,
I'm only working on this branch.
Lots of my team
have got lots of other feature branches.
I don't want to see those.
I just want to see my branch.
And being able to solo multiple ones,
I think that's really nice.
Yeah, it really cuts the noise out.
Yeah, definitely.
I guess one thing,
and this is another little thing
I reported,
but it would be nice if I solo a branch,
is to automatically solo
the remote tracking branch
of the same branch,
if that makes sense.
Because I'm always having to...
Yeah, in GitLens, it does that.
You can pick the current branch
and it filters things
to the remote and itself.
I also have a branch
that I've been working on
on the side of just a smart branching view,
where it will do that
for the default branch.
But if you're on a PR branch,
it also pulls in the base branch
that the PR wants to get merged into.
So you have both the local upstream
and the base.
So that way, you can see
all those three
to make it a lot easier
to focus on exactly what you want.
So yeah, we need to start bringing back
some of those features
into the client as well.
And that's a feature too,
like we don't have in GitLens
the soloing of a single branch
other than the current.
So like you can't just pick
a random branch and do it.
You have to go the opposite way
of excluding branches.
And so that's another area
we're trying to bring back in
to GitLens as well.
Yeah, this quite nice
has been a clean thing.
So another thing I quite like
is when filtering,
I can join the filter by authors
so I can select myself.
And it doesn't like
get rid of everything.
It doesn't filter by the author.
All it does is dim out
everyone else.
And I actually really like that
because when I first clicked on it
I thought it would just show
my commits.
But actually it shows all the logs
and just dims out everyone else.
So I can really see
what my commits are.
And I think that's way better.
That's really nice.
Just being able to...
Like one thing I use
that for quite a lot is
if I've got my feature branch.
So I'll be working my feature branch
it's been merged in.
And I'm just looking back
at all branches
and I want to say
has this been merged in?
If my commits are like
more obvious
and everything else is dimmed out
I can see much faster
the merge commit
for that branch.
So I can say oh yeah,
so this is my feature branch
there's the merge commit.
I can delete my local branch.
So that's quite nice.
Yeah, we think that there's
even a lot more that we can do
with this graph
that we have
to make it more customizable,
more filterable
to show other things
that are really nice
when you have a visualization.
Like,
one of the things
that we always talk about
internally
is like could we do the same thing
with just a PR
kind of like branching view.
Like if you just could
visualize how all the PRs
are stacking up.
Would that be kind of a mode
that this graph could switch into?
There's a lot of opportunities
to make the graph configurable
to what it is that you're actually
trying to see
and then maintain those interactions
so that you can kind of
take action on those things.
It's something that's always
on the top of our mind
and continuing to
push beyond just what people
expect from a typical
Git graph inside of a GUI.
Really thinking about what we
have the capabilities to show
especially with all the integrations
and everything that we have access to
to really make a visual interactive
and intuitive
visualization of what's going on
with everything that you're doing.
So it's good to hear
that you use those kinds of filters
because
everyone has different opinions.
Some people have come to us
and said like,
oh, I don't want to see everyone
else's commits.
I just want to see my commit.
So it really starts to turn into this
like, well, we might just make
this a really powerful
configurable
thing
that you can tune it
to what you want to see
and it will just show you
the things that matter to you.
With the graph,
when we extracted the graph
from the Gigpack and Client
to bring it into GitLens,
so it's like rebuilding it
in more of this component model
to try to meet the needs there
and as we were integrating it,
building this,
not a new component,
but is a fork of it
really heavily changed
and then we started building in some
new enhancements features
adding on to the graph
on what you can do
from dragging, dropping columns
to compact modes
to search results.
Like, there's a whole bunch of stuff
we started adding
into that component
and over the last few releases,
we've been bringing that component
back into
Gigpack and Client.
So now,
GitLens and the Gigpack and Client
and eventually other surfaces
will also use
that same component.
So we're continuing to
iterate, refine,
add more of these features
and we still have
experiments,
things that we've tried
in GitLens
that we want to bring back
and vice versa
of just like,
you know,
continuing to evolve
the graph
because yeah,
as Justin mentioned,
I think there's just,
there's still
an immense amount of
features
and I don't just mean
like checkbox features
but just different modes,
different ways
of visualizing
that the data there
that could have
really profound effects
on what you're trying to get done.
One of the features
that I'm really,
that I really like
about the graph
in GitLens
that we haven't yet
brought back to the client
is really rich
Git searching
so you can provide
you know,
like a kind of like,
you know,
your GitHub box
where you can put
a rich filter
of like filtering issues
and PRs
but you can do the same thing
of like filtering
authors
or looking for changes
or looking for
specific files
and we go
and highlight
just the commits
that affect those files
or just have that change
and you know,
we have a little mini map
that shows you
where all those are
so you can quickly jump to
where those things are.
So like there's a lot
of those features
that I'm excited to have
brought back into the client
as well
and just continue evolving
and iterating over that
because yeah,
I think there's just
so much more
that can be done
on that visualization.
How do you manage
because I know
there's the feedback.gitcrackin.com
where people can do
suggestions and things
and people can not vote.
How do you manage
prior,
obviously got the upvotes
to give you an idea?
Do you just
as a team pick
what you think is the best
next thing to work on
or do you
do you have like a process
to choose what to focus
on what comes next?
Yeah, we
we all look at that
and then blend it
with everything else
that we're trying to do.

It's just
typical project management.
It's like
we have all these features
that users want.
We have all these
business needs,
these things that we want
to do to try to grow
the business
and evolve the products
that we're building
and just trying to find
the best mix
of what we can do
with the time that we have.
The feature
board that we have
has really helped
with that
because it does help
things float to the top
that are really important
for users.
One interesting thing
about that board
recently though
is that
some people are starting
to abuse it now
and create bots
that just go
and upvote.
So if you're one
of those people
that's doing it,
please stop
because it means
that it's harder
for us to actually
see what people
care about
when everything
just has 2000 votes
and now we
have kind of lost
the context
of what users
really want.
But yeah,
it's a balancing act
like everything.
Yeah, and one thing too
is like
getting this tighter
feedback loop
and getting
the engineers
more involved
in that feedback loop.
Once we have
this nightly build,
you're going to want
to be more involved.
Like if I push
to change,
I want to be more involved
to see if it
fix the user issue.
It's not like
oh, we did that
three, four weeks ago
and now it's going to
come in a couple weeks later
and like
the tighter that feedback loop
the more involved
you are in that
and then the way
the way we structure
our engineering cycles
we're on
this monthly cadence
of releasing
and so it's
roughly a four week cycle
and for
three of the weeks
it's kind of like
two weeks of
full on dev
one week of testing
and stabilization
and one week of
quote unquote debt.
So like that debt week
is engineers time
to work on
anything to improve
upon the product.
Like it's not
sort of demands
from the organization
is not, you know,
it's really just for
the engineers to improve
upon that.
So there is, you know,
a quarter of this time
is is even outside of,
you know,
product in the org
saying, you know,
we should ship these features
or, you know,
like, there's these really important
upvote features.
There's still
a swath of time
for just continual improvement
chipping away
at really important items
improving keyboard accessibility.
Like a lot of those sort of things
are in that period of time.
I like your
the term
when you said about blending
because I find that even with
the podcast, for example,
I've got a lot of people asking me
to be on the show.
So I've got like a big backlog
of guests and stuff.
But then I've got
episodes I want to have on and stuff.
And that's such a great term,
like blending
the different things in.
But yeah,
it's managing different
different priorities
even within a business with clients
I work for.
You can feel the
you mentioned about
like tech debt
to working on tech debt and stuff
and more like infrastructure stuff
where like the devs want to
well,
we want to do this.
But then the business might say
that they've got UI changes
they want to make
and they're fighting saying
well, you can't spend time
on this tech debt stuff
because we want these business stuff.
And it's kind of like just
finding that right balance.
It's always quite an interesting mix, I guess.
Yeah, and it's hard.
Because there's not infinite resources
to do whatever you want.
You have to pick and choose
and that's a really hard thing to do.
Yeah, and there's no right answer.
Is the one other thing
like going back to your video
that you did,
one thing you spoke about
was something called cloud patches.
And one thing I really liked
is that there's a button saying
share merge conflict.
So that's that's made me laugh
like share the pain.
Yeah, I wanted to talk about that
especially, you know,
earlier we were talking about
kind of the noise generated
in front base development sometimes
when everyone has branches
that they're all pushing to main.
Like cloud patches
are a way for us to explore
how we might help devs collaborate
earlier on code
that without the kind of like noise
of pushing branches
to the repository, right?
So cloud patches, you know, stemmed
from hearing some of our customers
that actually use patches every day
which is still surprising
but there are companies that work this way.
They share code with patches,
they email them back and forth
to each other
and that's like how they collaborate on code.
So we thought like one,
could we just make that process
easier and streamline it?
So if I have some code that I'm,
you know,
maybe not comfortable pushing up to a branch
or I just want to get some feedback
from a senior Devon,
can we facilitate that sharing process
in a much easier way
that's a little more private
that doesn't have to be pushed up
to a main branch
between one or two or three developers
and that's what cloud patches,
you know,
at its core is trying to do
is just really say
I have some code
that doesn't have to build,
doesn't have to do anything.
It might just be a list of
to do comments
in all the files
that I need someone to go look at.
I can just really easily package that up
and just send it over to someone
and if they're using any of our tools,
they see that pop up
and they can go access it,
they can review the code,
they can, you know,
respond to it or merge it
or do whatever they want
with that cloud patch.
So yeah, like at the core,
that's what cloud patches are
just this like way to make it easier to
as frictionless as possible
and as privately as you want to
as possible share
and collaborate on code
with someone else
and there's a lot of implications
that we're exploring on like
what that can enable
and the merge conflict resolution
is something that we hear constantly.
We have people that really like
our merge tool
and get cracking client
is very visual,
it's very intuitive,
but there's still times
where people say like,
oh, I have to open up a video chat
with another dev
to show them my merge conflict
and help me resolve it.
And so one of the use cases
that we're exploring
with cloud patches
is like, well,
if you get into this state
and you don't know how to resolve it,
could you just package that up
as a patch
and send it over to someone
who could get their repo
into the same state,
fix the conflicts
and then just respond back to you
with another patch
and you go apply that
and now your conflict is resolved.
That seems like it would solve a really
large amount of pain
that we hear from users all the time
and we think that
it could have a really huge impact
on again that ability to collaborate
on code
that isn't kind of inherently built
into any systems that we have,
but it's technically possible.
When I watched your video
and saw it,
I was initially,
I was thinking,
well, why not just use brunch?
It sounds like you may as well use brunches,
but as you were saying it then,
I'm kind of thinking that
because you mentioned about share it privately,
I was thinking actually
because a lot of the stuff I work on
is a small team
where it's kind of like,
it's a private repo.
Well, I guess if you're doing like
open source development and stuff
where if you did do a brunch as public,
then this is perfect
if you can privately share something
and it not be a public branch
on the open source repo.
Yeah, it definitely gives you that ability.
But even if it's not open source,
you just may work on a large team
and there's just inherent human interactions.
Like I really only trust Justin
to look at this before it goes to the wider team
because I don't want to be judged harshly.
And whether that's good or not
is a different story,
but the reality is dynamics like that happen.
We really want to enable
really early collaboration
because if devs communicate
and collaborate on code
really early in the process
of just throw it over,
it's like here's pseudo code
of where I'm thinking about going with this.
Does this structure look good?
That sort of thing,
just continuing to evolve that
will end up with a far better PR
at the end
that it will get merged
a whole lot easier
and just far quicker as well.
And you won't get to the stage
that happens a lot
is something shows up at PR time
and you're like,
we really should have done this
in a different way
or like we really want to go back,
but some costs are real things.
So it's like, okay,
well, maybe we'll just merge this
and we'll eat the debt later
and those sort of challenges.
So the more we can collaborate
and if starting small
with one trusted partner
enables that collaboration
way earlier in the process
and then just be able to expand
the circle very easily
or jump right to a branch
or to a PR
and continue that flow
is something that we really want to enable.
Yeah, that's quite nice.
Like definitely bringing collaboration earlier
and I found doing pair programming
makes a massive difference with that.
But I don't like pair programming
all the time
cause I find that's full on
if you let one client
to work for a couple of years back,
it was like 100% pair programming
and that was just really full on.
So this kind of feels like
still allowing you to bring
that collaboration sooner,
but you're not like always in a call
always pair programming
you can bounce things backwards and forwards.
So yeah, I like it.
It brings the async nature into it as well
as like it doesn't have to be
right then and there.
And we're looking at many different
lows of like, where it can apply.
Like even we're looking at
suggesting changes to an existing PR
rather than just purely reviewing it.
Like if I could just go in my code editor,
make the changes that I'm suggesting.
I have all rich intelligence
I can compile if I,
you know, like any of that sort of thing
and I can package that up
as a set of changes
cause I don't really want to commit
my changes back to your branch
because then A,
they'll be live and go with this.
It's far less a suggestion
if I'm committing it back.
And you know,
so like being able to apply that
make that really easy to
then accept those suggestions,
take part of it
cause it's just a patch
you can pull down partial that.
And so we're really just trying
to improve that experience as well.
Yeah, that definitely makes sense.
So I'm aware we're kind of like
quickly running out of time.
We're actually,
I don't know that you've got a hard stop
on the hour.
So before we do uphook,
shall we do dev tips?
Yeah, let's do it.
Awesome. Yeah.
Yeah. So one thing that I had,
you know, I'm really interested
in these large language models
and how they're,
you know, just changing
so much of what we're doing,
especially in the dev space,
but just overall,
and there was a great YouTube video
by Andre Carpathi
who's at OpenAI
and it was just like,
you know,
it's this intro to large language models
on YouTube.
And it's,
you know,
it's about an hour long video,
but it's a really accessible video
to kind of anyone
and it just gives you sort of this
intro to how they work,
the different modes to like
where they can go
and some of the,
even like security
and vectors
to attacking them as well.
So it's a really interesting talk.
They're definitely impressed by it.
So that would definitely check that out.
It's funny,
I've actually got that
in a browser tab Open.
Eight minutes and 49 seconds into it.
I obviously got pulled away from the kids,
but it's in a browser tab,
so I can finish it.
But yeah,
you could tell like from starting,
this is going to be good.
But yeah,
I should like
drill in too many things,
but I will definitely include that
in the show notes.
Awesome.
Yeah, mine
is something that I saw
on LinkedIn
just a day or so ago.
And so I can share
the link with you to it.
But it's a post from Brad Frost,
who's the person who kind of
pioneered or developed
the whole atomic design,
atomic components,
kind of philosophy.
So he's like kind of bridging
the gap between design and development,
which is a space
that I'm really interested in.
And the specific post
was talking about like
how important it is for devs
and designers
and designers to communicate, right?
Not have this kind of like wall
that things get thrown over
or like kind of tossed back and forth between,
but talking about like
how critical it is for devs
and designers to be more on the same page
throughout the entire development process,
because it just makes things a lot easier.
It keeps everyone from wasting time
and it really informs each of those groups,
like what the struggles of the other is, right?
Like when designers know
how difficult it is to build something,
that helps inform the things
that they're designing.
And when developers know
kind of like what the design process is,
the more you can bring those in sync,
ultimately, I think products
come out the better for it.
So I can share that link to that post,
but it's something that I just read recently
that really resonated with me
as someone who's kind of lived on both sides
of the kind of design and development space.
It's quite interesting with,
you hear a lot about devs
and operations
and the wall and everything,
and QA as well.
Like just bringing,
like as you say designers,
the QA team, operations,
all of those people together
to collaborate and do this sooner rather than later,
because the later you leave it,
just like with git branches,
you can get divergence with long live branches.
If people don't communicate,
people diverge of separate ideas
of what's going on,
and then it's much harder
to bring that together
like later down the line.
Yeah, totally agree.
Yeah, definitely.
Not everyone has to be a developer,
but just keeping the teams together, right?
Like having strong cross-functional teams
rather than walls between them.
It's like it doesn't happen for design,
and then dev,
and then QA,
and test it to dev opsite,
the more that you can unify that
into one team that's working together,
it just up-levels everyone,
and you have far better outcomes.
Yeah, definitely.
So my dev tip is,
I was just trying to find something
that was on topic,
and I know a lot of people that use git,
but haven't used it that much,
don't know about the reflog.
And this has saved me quite a few times.
It's a log of a lot of things that happen in git,
like which is much more granular
than just the commits that you see as you go.
And quite often,
like if you completely screw up and loot,
think you've lost something,
you've done a git reset or something,
or you've done something
which you think you've lost or you commit.
There's a good chance
if you've committed it at some point,
it's still in the reflog.
And a lot of git users
that maybe haven't spent time
trying to learn git,
I've probably never heard of it.
And I think just knowing this exists
means that you can be more relaxed
about doing things like rebasing,
which, to some git users,
that's scary,
which, actually,
that should be a fundamental thing
that everyone knows how to do.
But I think just knowing
you've got this backup as the reflog,
I think that's good to know.
Yeah, and I think that we make use of that
with our undo feature.
So, like, the client has the ability to undo.
And I think what we're doing
is we're going back through the reflog
and saying, like,
well, where are you before?
Well, we'll just take you back
to that point in time.
I didn't even know you have an undo feature.
Is that just control size or something?
I think control, yeah,
control Z,
and there's a button in the toolbar for undo.
And it will tell you if it's possible
or not, depending on what you've done in the past.
But...
I feel really dumb now
because it's, like,
yeah, it's, like, right up there
in the centre of the toolbar,
a big button saying undo
and it just knocks in it.
I think, because I use keyboard shortcuts,
I don't even look at the toolbars.
I just, like, learn the shortcuts
and then do those.
That's quite cool.
It's really nice.
Cool.
So, before we wrap up,
where's the best place for listeners
to reach out to you?
If you've got any questions,
I know you've mentioned the Slack.
I can put any links as well
that you're mentioning,
the show notes too.
Yeah, we have our GitKracken Slack channel.
We have GitLens,
there's an open-source repo
that has discussions
and comments
and issues
that you can suggest on there.
We have feedback.gitkracken.com,
which is where we have
all of our features
for the client
that we listen to users' feedback on.
So you can suggest things,
upvote things,
comment on things there.
And then, yeah, we also have Twitter,
which is where I think
you reached out to us on.
So we're all over the place,
wherever you can find us.
We also have a...
While the CLI is not yet open-source,
it should be coming,
but we do have a repo on GitHub
that is for issues and reporting,
and that's where the releases
also happen
until we get that
fully open-source.
And I think the same
for our browser extension,
which should also be open-source
in the near future.
Very nice, very nice.
Well, cool.
Well, just thank you both for joining me.
Thank you for GitKracken as well.
I'm really enjoying it,
and thank you for joining me on the show.
Okay, I'm glad to hear it.
Thank you.
Yeah, thanks for having us.
Awesome.
You're welcome.
And thank you everyone for listening.
I'm a quick reminder
that this podcast is sponsored by Eversdack,
which is my own company
providing software development
and consultation services
for more information.
Visit Eversdack.com.
And if you enjoy the podcast,
please do help me spread
the word on social media.
I normally use the hashtag
on HandledException,
and I can be found on Twitter,
X, at Dracam,
which is D-R-A-C-A-N.
But the best place to get in touch
is on Discord,
et on va inclure les liens
à toutes les choses qu'on a mentionnées
dans les notes de la show
qui peuvent être trouvées
sur un HandledException podcast.com.