095: Twigg with André Bianchessi
Hello, gophers. You're listening to go podcast. I'm Dominic StPierre. And today, we are receiving Andrey Bianchessi.
Andre:Yeah. Hello. Hi, everyone.
Dom:So you are I I came across your post on Reddit regarding Twigg, the version control system, and I was immediately extremely interested to to hear more about that. But before we jump into anything, can you give us, like, a small I don't know. You know, a small history of your of your path so far in tech and whatnot, you know. Where are you coming from? What what kind of work have you done?
Dom:And how did you discover Go? And things like that. So, you know, a small a small history story we we know a little bit too better.
Andre:Yeah. Awesome. Of course. Yeah. Just before that, Dom, thank you so much for having me.
Andre:It's it's great to be here. Great to be on the on the podcast. Maybe I can start with so I I studied mechatronics engineering in college. I did my master's in machine learning, and that's when I didn't study computer science, but I knew I enjoyed programming since the first years of college. And so I started working with software ever since I left college, ever since I left the university.
Andre:I have so I now it's, like, seven years of experience in total. Seven, I I think. I'm not that good with the the math there. But, yeah, seven, eight years or so. What I did is I worked mostly on back end in my, like, my first two years or so.
Andre:And then I started working at at Google. So the the last three and a half years I worked at Google, and that has everything to do with why I'm doing what I'm doing now. We'll get into that later. And I'm originally from Brazil. I lived in Canada for one and a half years.
Andre:So my last like, before I quit to start, like, building my business, I was I was in Canada. So I worked at Google for two years. And then one and a half years in Canada, worked I lived in Kitchener. This is, like, near Toronto. I lived there for one and a half year.
Andre:Then I came back, and now it's been almost a year since I since I quit and started my own thing. Yeah. I think that's
Dom:a No. I guess
Andre:minute summary.
Dom:Yeah. That that is yeah. I I have so many questions now. So I'm I'm not so what is what is this the thing that you studied? I I I'm not sure I heard that before.
Dom:Match how do you
Andre:Oh, yeah. Yeah.
Dom:What is that? What is that?
Andre:Mechatronics engineering. So it's basically like I think it's the term we use to fool ourselves that we're building transformers like the robot transformers. No, but yeah, like in all seriousness, it combines So there's robotics, there's software, there's mechanical, a bit of everything, I guess.
Dom:Nice.
Andre:It's it's relatively new. Right? It's it's part of the mechanical engineering, but it just has more, like, some of the software, some control theory, which is the hardest part by the way. So yeah, I guess a little bit of all of those.
Dom:Fascinating, fascinating. Okay,
Andre:yeah. I loved it, yeah. I really enjoyed studying. That's why I did my master's afterwards. I was like, yeah, I actually enjoyed studying it.
Dom:Very nice. Okay. So so let let's let's jump in because yeah. So Twigg, a version control system. Well, the obvious question that most people would ask is is why a yeah.
Dom:New In 2026. But it on the other hand, I've I've been hearing a lot of things about Git in the last, I don't know, let's say two years maybe and things like that. So anyways, I will I will let you go, but yeah, why exactly?
Andre:Yeah. And by the way, you you touched on that. Yeah. I've been noticing like, it is a recent trend. Right?
Andre:Like, I think for for the past, like, fifteen years, like, no one like, nothing came out in the, like, the version control space. But in the past, six months, there there there's a lot of news there. Right? So the timing really is interesting now. But in my case, what happened was so Google doesn't use Git internally, only for, like, public facing projects.
Andre:I worked I worked on Gmail and for the most part, and then, I guess, for, like, less than a year, like, my final time there were at Chrome. So Chrome is an open source project, so they use Git for that, like, a modified Git with, like anyway, a platform built on top of that. And Go itself also, like, they use Git because it's also open source. But for everything internal, they don't use Git. They use an an internal thing, which was Piper, and then it switched to Figg.
Andre:Now switching again to, like, the jujutsu. But also, like, the code review part, it's it's different. So it's not on GitHub. Right? And, honestly, like, the difference is that it's just much simpler to use.
Andre:I we'll get into more detail on that later, I'm sure. But suffice to say, like, it's different than what people are used to when they're working with, like, pull request model. Right?
Dom:Mhmm.
Andre:And so when I left, like, I I decided I left, like, I wanted to build a business with my my two brothers who I who, like, were were business partners. They also code. Right? And when we started, I am like the technical leadership of our company, of what we were building. So I review all the code, right?
Andre:So when I was reviewing everything, like, I was so, so frustrated. Right? I was I missed the internal thing we had at Google so much, so, so much that I still like, I just started to started to look for alternatives. And while there are, like, there are especially in the version control parts or, the client, so, the the Git space, there are solutions out there. So, like, the what Facebook uses, what Meta uses, it's called Sapling.
Andre:You can download that, and it works on top of of Git, and it's very good.
Dom:Oh, really?
Andre:But then yeah. It's very interesting. Like, I I recommend trying it out. So I I started using using Sapling, but what happens is eventually, like, you have to use this on top of some Git server. And at that point, like, the workflow like, the benefit of the workflow kinda got lost.
Andre:Right? Because I still had to work on branches and reviewing branches, and I was reviewing like those PRs, are like 10,000 of lines long, right? Yeah. And this is what motivated to me. I have an idea of what I want, and then I kinda fell into this rabbit hole of how these version controls work, what the differences are between them.
Andre:And I was like, how hard can it be, right? Let me quickly do a prototype. Turns out it was pretty hard.
Dom:Yeah, you imagine.
Andre:Getting a prototype working is pretty easy, right? But then I was like, Oh, you know what? There's this problem here. Let me start over, right? So I got it right on the third iteration Third time is the charm.
Andre:Right? And then we started using it internally only at first. Right? And we were building, a completely different thing. We were building, like, an agricultural optimization software.
Andre:So totally unrelated. But then we were like, hey, guys. Like, this is this is this is we might this might be something good. You know? Like, maybe maybe let's focus on on this.
Andre:Right? And so we decided to, like, let's, like, drop whatever we the other thing we were doing.
Dom:Oh, really?
Andre:Started focusing on it. Yeah.
Dom:Oh, wow. I I was I was going to say, wow. Okay. Agricultural automation seems seems also very interesting. Okay.
Dom:Okay. But, okay, let me let me try to back up a little back up a little bit. So I want to understand exactly the pain point. So you you yeah. The size of the PR is something that we mostly all felt at some point for sure.
Dom:Mhmm. Go ahead. But regarding the the trunk base, the removal of branches, that is is that also a pain? Well, I'm I'm curious to hear about, you know, was branches giving you any any kind of pain or it's maybe because of branches that we do have these gigantic PR and whatnot. So what what what is the problem exactly?
Andre:Right. Yeah. Very good question. I guess, like, maybe to start is, I think I always had like, I never liked Git. Like, I I suffered a lot from especially, like, when I was starting.
Andre:Right? Then I think what happens is that eventually you get used to it. And now what I'm talking about is even, like, the day to day usage. Right? And this might 100% be just skill issues.
Andre:Right? Maybe I was just dumb. Right? Like, the commands were always complicated to me, but that it wasn't uncommon for me to be something like, oh, you know what? Like, I don't know what's going on.
Andre:I got in a bad state. Let me just delete everything and clone again. I think we've all done that. Right? Yeah.
Andre:And it's crazy that this tool is supposed to be to save our files. Why do we sometimes lose work due to it? Right? But anyway, I got used to using it. Eventually, things were working well.
Andre:But when I started working there at Google, saw this completely different way of working and then I got used to it. And then I realized how different things can be. Right? So I guess the way this translates practically is what the work used to be like. So first thing is, I guess, like, can you work for example, let's talk about the branches thing.
Andre:Like, branches by themselves are not a problem. Right? They don't like, they add some complexity, but not that much. But what inevitably ends up happening is that companies, they adopt some form of, like, we develop the features using a branch, and then, like, you send this for some seniors to review. Like, let's say you're the junior on the team.
Andre:Right? So you write, like, some code, and then you send this to someone to review. And at that point, you're blocked. Right? Like, you're waiting for them to approve your changes.
Andre:Oh, so you have two options. Either you write a bunch of code at once, and then, like, you send this for someone to review, and then you go home and that's no longer your problem. And then you're not blocked because you wrote a bunch of stuff and you can go home. Or you do make these small incremental changes, like you create a small branch, you write something small, ask for feedback. But then you're gonna have to stop working and gonna have to wait for someone to review.
Andre:Right? And that's why you usually end up had like the thing pushes you towards writing like a lot of changes at once. Right? Whereas like what Google does, and this is the same in other big tech as well, like Meta, Uber. They have internal tooling that works similarly.
Andre:You create stacked commits. Right? So you write a small change. You send this to be reviewed, to be reviewed, submitted, but then you don't stop working until that thing gets reviewed and submitted. You keep working on top of it.
Andre:And what gets reviewed is so you create the first commit. When you create another one on top of that, when the reviewer is reviewing the second one, they're gonna only review the diff from so number two to number one. And then when you add another one on top of that, you review only the difference from number three to number two and so on. Right? There are tools that allow you to do this in Git.
Andre:I think one is, like, h stack, for example. And it helps, like, creating branches off branches and, like, creating the pull requests in that way. But what I saw is that there is enough friction that you end up not doing that. Because in theory, people could do that manually, right? So why doesn't anyone do that?
Andre:And at the end, you end up with these two things. First is like you have to juggle these wrenches. And it's common to see like what is actually in the staging environment, what is actually in prod. And it's like like it's not the end of the world, but like there is complexity there. It's common to know this like what is there, what isn't.
Andre:When whereas when you when you work with trunk base, when you work with like, there's one branch and everyone tries to make things work. Course, like sometimes code breaks and that's fine. But you really try hard to make the code always be deployable at the latest submitted commit. Right? That just makes things so much easier, like in terms of what is in prod and what isn't.
Andre:Right? You just see like where do we cut? We cut here, so what's below this is not in prod. What is above this is in prod. Right?
Andre:And then in the second part, this thing about reviewing the code. Right? When you're working with these small incremental steps on top of each other, what ends up happening is that you review 10 lines at once, ten, twenty, and not like those hundreds of lines at once, right? So that's why like when my day to day work was most of the work, for example, when I was implementing a feature, like a lot of the work was like, let me just do a bunch of these refactors that are obviously like, that don't change anything. And then at some point you're like, okay, now I'm changing things like this needs a better review.
Andre:Then the cost of someone reviewing this is much slower. Because the the I think we all experienced this, that the cost for review is definitely nonlinear. It's like one line, like less than a second, two lines less than a second. And then like, eventually this like blows up. Right?
Andre:It's like like reviewing ten ten thousand lines is like
Dom:Never going to happen.
Andre:Yeah. Exactly. Never gonna happen. Right? You just accept it.
Andre:And when I when we started using AI for development, like, I I realized this got worse. Right? Because AI writes a bunch of code. And then what I'm seeing is people are sometimes choosing, like, oh, let's just not review code anymore, which
Dom:Yeah.
Andre:I don't think is a good idea. Like, I've seen some horror stories of this. Right? It's like, yeah, sure. You're you're building like a landing page and where the success criteria is like, yeah, this needs to look good or build or whatever.
Andre:Like, sure, there are use cases, but there are many cases when that is definitely not the case. Right? And then you end up with something which is just unmanageable. Right?
Dom:Yep. Yeah. Let let let me ask a couple of questions regarding well, let's start with what is in production. Because what you just described when I when I started well, obviously, Git was not there yet. I started with VisualSourceSafe, which I think could be considered trunk base.
Dom:But I I also use a subversion at some point. But in in source safe, you were doing some, you know, check ins and check out. So basically, you add a central server. If I check-in check out a file to work on it, nobody could do that. Obviously, it it's not like that with Twigg.
Dom:I understand that. My question is that well, I I I have so many questions. First of all well, yeah, exactly. How can how can we work multiple people on the same file on a trunk based approach?
Andre:Right. Yeah. Good question. Yeah. I saw, like, many like, in the version control space, like, there was this shift which, as far as I know, git introduced, git and mercurial both.
Dom:Mhmm.
Andre:Which is, like, the first version is, SPN. I didn't use SPN. I only learned about it when I got into this this rabbit hole of the version control history and stuff. It's like file based. Right?
Andre:The the the first versions. You get a file. When you when you when you're grabbing a hold of the file, no one else can edit it. You are you can edit it and push it, and the files are changed and everything is combined, like, on the server. Git and Mercurio, they introduced this idea of, like, no.
Andre:Like, you're versioning everything. Right? You when you check out something, when you get the code, you get everything. You make your changes. And when you push them, like, there is this merging, the combined changes that everyone made.
Andre:Right? So Twigg falls into this category, is like it's not file based. It is very similar to Git. It is very similar to Mercurial when you think about what the day to day is. So you do you you do like Twigg.
Andre:Tw is like the the binary name. Twpull, like, that gets you the code. You and then, like, you just write something. You change your files, and then you just do Tw commit. That creates a commit.
Andre:You do push. That pushes your commit, so pushes the changes. And then they get merged similar like, in in a similar way that a PR would be. Right? So the collaboration part is very similar to what you're used to in Git.
Andre:The difference is you don't have to first create a branch and then also think about, like, merging or rebasing. Like, Twigg only, like, only allows rebase, which is, like, just named submit. But what it does internally is that, like, it it rebases the changes. Because that that's also, like, something that people keep, like, losing a lot of time or, like, do I merge or do I rebase? And there are all these discussions about why rebase is better.
Andre:Twigg a lot of the stuff is just Twigg being opinionated. Right? So it doesn't ask the user like which one do you want. You just submit and that rebases your changes. So, like, combines the changes that me and you could have done to the same file, for example.
Dom:In in your video, you you are showing something that, yeah, I immediately wanted to ask a question about. So you showed something like, okay, yes, we can we can submit some small changes and continue to work, and the person can review that. Let's say the version one, ask us to do some changes, and now we can return to that version, change this, resubmit, and and that that kind of changed the history, if you will. What happens if if there is multiple people that already pulled that v one and continue working? I mean I mean, I don't know if you understand where where I'm I'm I'm I'm I'm at at the moment because obviously, I've I've been using Git for for so many years now that everything that is not Git is see seems to be all wild would would you know rewriting history is is like very bad and git we we all know that so how does it work?
Dom:How how can you modify a already committed version and and go back there and and now it kind of automatically fixes that for everyone?
Andre:Right. Yeah. No. Very good question. In in fact, I I agree.
Andre:Like, this part about overriding history, like, is is is definitely bad. Something that usually we don't want to allow. But that's why in Twigg, we introduced the idea of there are basically two types of commits. They are the submitted ones and the not submitted ones. The submitted ones are immutable.
Andre:No one can change them. You can't amend. The ones that are being reviewed, they're not marked as submitted yet. Those can be amended. Right?
Andre:The idea is you push something, so you have the change there. And whenever you push a commit, they all they the the commits themselves have versions. So when you push one, it's v zero. When you push again, it's v one, and so on. And then you iterate on those versions by amending the commit.
Andre:That changes the commit. During the review process, it's also important to be able to see what changed, like, between the versions. Right? So you wanna see, like, what is this chain like, it forces you to think in in changes really, which is kinda what we do in Git at the end of the day despite being, like, a commit is a snapshot of all the replicas, so it's all the files. But at the end, when we are merging or rebasing, we are thinking of apply this change to the top there.
Andre:Right? So you create the the the versions by amending them. You see, like, you you iterate based on on feedback. And when you're ready, you click to submit. And once that commit is submitted, like, no one else can change it.
Andre:So you should try to amend the commit like that's not changeable. What you can do is revert. So you you create a new commit that changes, like, undoes whatever a submitted one does. And also, something else important is this idea of amending the the idea that it creates new versions is just so that actually, like, at the end of the day, commits are immutable, even the non submitted ones. Right?
Andre:The the what happens is they get a a like a number that identifies that intent of whatever you're trying to do. That's like the C1C2C3. That's the server saying, like, this is the commit number 3. Right? As you amend it, you create the V0V1V2V3, and so on.
Andre:But commit 3V0 is always commit 3V0. Like, no one can change that. And this helps with that because that's something you can do with Git, and I've I've shot my my foot off doing that. Yeah. Of, like, losing history, which you can do in Git.
Andre:In Twigg, you can't. What do the only thing you can do is when you when you amend something, you create a new version, and that's the one that shows up, like, in the CLI. Right? But if you do Gotcha. Like, log all, that's gonna show all the previous versions, and you can even see, like, the first version was created.
Andre:It was amended, became the v one. It was amended again, became the v two, and so on. I don't know if that answered your question.
Dom:Right? Well, yeah. You might have gotten a little Yeah. A little bit. Let let me ask you a follow-up question then.
Dom:So how does the reviewer can can pull the not submitted changes and not and, you know, not the rest of the team, for example. Because obviously, they don't want to to pull anything that is not submitted yet. I guess they cannot do that.
Andre:Right. Yeah. Yeah. Yeah. But so by default, like, when you run pull, you're only pulling the latest submitted, like, the the latest submitted commit.
Andre:That's it. Mhmm. So when you when you run TWO pull, you're pulling whatever was submitted because that's what we want at the end of the day. That's this idea of, like, there's one version of the code that matters, which is the trunk, which is, like, which would be, the main branch. You can pull a specific commit that is like, someone is working on.
Andre:Right? And we do that sometimes. Like, someone creates, like, a change, asks for me to review it. I'm gonna do, like, oh, this looks good, but let me just change this little thing. So I can do like, you can do tw pull number of the commit.
Andre:Like, that commit gets pulled. Like, it gets you download it to your machine. You can amend it. This is gonna create a new version. And when you push it, it's gonna create a new version on the server.
Andre:Right? What can happen here? And this is something I had a like, this is our current solution. We can change this, like, by the way. Like, what happens if, like, I push something and then you push a different version.
Andre:Right? Do we merge them? What I decided to do, which I think is just simpler and which is what we probably want at the end of the day, is that it just it's it's the equivalent of a force push. Right? So if I create a commit and I push it and you do like, you pull that commit, you amend it, you push it again, and then I in the same time amend and push, like, whoever pushed last would be, like, this final version that is there on the server.
Andre:But all the versions are there. Not nothing's ever lost. Like, there isn't a command to erase a commit. Right? You can always pull, like, older versions, and you can restore them.
Andre:So you when you restore, you just create a a new version of the commit, which is the exact same thing as whatever that version was that you're restoring.
Dom:Okay. And as the reviewer so if I understand correctly, so I would basically pull this specific commit number on my machine. How do I get rid of that after my review, for example?
Andre:Alright. Yeah. There are two ways. Like, what at the end of the day happens is when you pull, Twigg handles this this thing of so if I had, for example, if I had commit number 10 on my machine and after I pull I see that commit number 10 was submitted, Twigg is gonna mark that commit as like, oh, okay. This one was submitted.
Andre:It marks this this version that you had as, like, obsolete. Like, That one is an older version, not the latest version. And what you're gonna see in your machine is just the latest versions on top of each other. Right? If you for people who have worked with Mercurio before, this concept, I was heavily inspired by what Mercurial does, which is this idea of commit obsolescence, I think it's called, which is basically like, they are our commits.
Andre:And then when you create a new version of it, like commit like Mercurial doesn't have the versions internally as Twigg does, but it is the same idea of, like, you mark a a commit as obsolete and it has, a successor, which is, like, this is the new version. That one is old. Ignore that old one and look at this new one, basically. Right?
Dom:Okay. Yeah. Interesting. May maybe just one last question before we we switch to more technical aspect. So what what happened, you know let's have a scenario.
Dom:Let's have a catastrophic scenario. We all like that, I guess.
Andre:Great. Great. Yeah.
Dom:Yeah. Some something something the the last release of our software exploded on production. And now we need to, I don't know, roll back a little bit. We need to go to a safe spot. So usually with, you know, with branches, we we could, you know, we could go to the last tag or something like that.
Dom:I don't I don't know exactly know Uh-huh. How how all our destination works and whatnot. But, you know, with git, there's there's usually an easy way to just okay. Let let's let's return quickly to the last last version. So in in trunk base, you know, you basically it's it's I don't know.
Dom:How do how do we do that?
Andre:Right. No. Yeah. Good question because we get this one a lot. I think what happened like, the industry is definitely, like, set like, most of the industries has settled on the, like, the branch based collaboration.
Andre:But in my opinion, like from my experience, is more complicated, but we got used to it. Right? In trunk based, like when you have one trunk, it's actually simpler. The idea is like, for example, let's think of this scenario. Like, that we we submitted, let's say, like, bunch of commits, like, 100 a 100 commits, and only later we realize, like, note like, all the tasks passed, but, I don't know, something broke in production, and we need to push something to production.
Andre:You actually just go, like, to a previous so let's say that they are, like, commits from zero to a 100. Let's say commit number 50 was okay. And from 50 to a 100, everything was broken. Right? What you do is you just you just deploy what whatever was in commit number 50.
Andre:Right? So you in Twigg, for example, the the equivalent of git checkout would be, like, go to. So t w go to and c 10, for example. That checks out the code to to commit number 10. And if you need to add, like, hotfixes, you can do that.
Andre:Right? You can, like, wait. Let me go to commit number 10. Let me add this, this, this, and that commit on top of it, and then we push from here. You can do.
Andre:Right?
Dom:Okay. But what what happened with the the 50 other commit that that come after Dan? Is this, like, a a merge or something that that there's a rebase to be done or something like that?
Andre:Yeah. Yeah. No. The the the other ones are lost. You're you're right about, like, you're not pushing those ends.
Andre:Right? If you
Dom:want No. But I mean, if you if you do the odd fix and at some point, everything the projection is back on, everything is good, now we need to fix the the the 50 that broke, but we added some three hotfix, for example.
Andre:Right. Right. Yeah. Eventually, like, the hotfix will will be submitted. Like, you wanna rebase them and have them submitted.
Andre:Right? The idea is you can, like, check out to commit number 50.
Dom:Apply You would you would not submit the hotfix. You you would you would just apply that locally and and build that?
Andre:Well, let wait. Let me think. If I'm thinking in terms of, like, a hotfix that you act that actually fixes the code, so that's something you want to actually submit at some point. Right? If that's the case, what you do is, like, you can create a commit off of another one in the same way that you would create a branch off of another one, like, off some commit.
Andre:And then you can, like, you can apply, like, the create this commit that changes, that does this hotfix there. You run your CD. Like, you run the job that actually publishes to production. This will publish, like, the fixed version. And then once everything's back online, like, you actually want this this hotfix to be reviewed, submitted, and then you're gonna work at this point, you pause the CD.
Andre:Like, you stop pushing until everything works. When you're ready, then you launch you launch the CD or, like, you you launch the deploy the, like, the launch, the job, the deploys things with the hotfix included. Right?
Dom:Okay.
Andre:Like, sure. There are cases, like, you can't there isn't one simple solution that, like, just makes everything super easy. Like, we have a bunch of changes we need to review, like, revert all of them. Right? And practically, like, this never like, in in the three and a half years I worked at Google, like, this never happened, for example, especially because you you usually are judicious about, like, what you're merging, and you use feature flags for those kinds of things.
Andre:Mhmm. So, like, I'm I'm creating this this feature. You use a feature flag, which for those that are listening that might not know what this is, it's really it can be as simple as, like, a boolean in the code, which is, like, if false. And then you just change that false to true. Like, now your feature your feature is enabled.
Andre:Right? And then, like, if things are breaking, you just revert whatever, like, revert the flag. Now the flag is off. The code is safe. Right?
Dom:So that could be how you would experiment something in in this, you know, in in this model, for example. So because
Andre:Yeah.
Dom:At this moment at this moment, we'd get when we want to experience something. We just we just boot a new branch, and and we might we might just delete it at some point. So
Andre:Yeah. Yeah. In Twigg, like, you totally can. Like and and we do that sometimes where, like, experimentation is is is cheap. Right?
Andre:It's like you can't just start writing code, like, creating commits on top of each other, test things out locally and all that. Or even in production if you want to, like, you can create, like, you can create, like, commits on on top of others, like, town, like, not not on top of whatever has been submitted. We just usually don't want to do that.
Dom:No. Exactly. Yeah. But how do you experiment something then
Andre:if Alright. Yeah. We we experiment with with feature and and this is this is in our code base a lot. Like, there's a package called like, it's called feature flags, and we actually deploy it that way when we're testing features out. Like, we deploy it for ourselves first.
Andre:So our repository says like and I think that shows just how simple you can do feature flags. Like, you you don't need a a crazy complicated setup to automatically trigger feature flags based on user preference or user location and all that. It can really be like, if username equals my name.
Dom:Like The the thing with feature flag is that for me, it's it's already one step further. I'm you know, I have branches you you would not believe, you know, some sometimes I I want I want to rewrite my my back end as a service and say, you know, I I will remove that and and use Postgres. So I I don't know. I do I do. But again, the yeah.
Dom:This this is probably it boils down to I shouldn't I should probably never have created these these branches anyway. So yeah. I I I kind of get what what you're saying.
Andre:But, yeah, that like, I I think it's important to say, like, this is this mode of collaboration is, like, is one way of collaborating, has a lot of strengths. Maybe it's not like I I don't I'm not sure one could argue that, like, this is definitely the best one for all scenarios, that nothing ever is. Right? There are trade offs for sure. Right?
Andre:For example, this this idea of the thing itself about collaborating in small changes. Like, yeah, they're faster to review. Sure. They're easier to review. You'll get safer code.
Andre:Yeah. But, like, yeah, not reviewing code at all has it, like, has its places, for example. Right? Maybe there are workflows in which
Dom:Maybe.
Andre:In which yeah. Maybe. I don't know. Like, I don't Yeah. A lot of it is a lot of it is taste, honestly.
Dom:Oh, yeah. Yeah. But I I I would be surprised if if nobody was doing but, again, I I like the idea of reviewing small changes, but I I also you know, if I put myself into into place where I would be in charge of reviewing a lot of teammates' small changes, now your context switching starts to be way I don't know. There's way much context switching now because, yeah, you could you could receive a small a small change, you know, from place a, now place b, now place c, now you are kind of all over the place. It's is it is it not as tiring as receiving a a huge PR, for example?
Andre:Yeah. In my experience, not so much, especially because I think two things. One is you remove a lot of the a lot of the border plate into, like when it's easy to see, like, oh, this is just adding the necessary example, let's say you're adding an additional parameter to a function or something. Like, you create one comment that is just doing that, and reviewing that is very easy. Right?
Andre:You don't need much context. Like, oh, okay. I see, like, first, I see this is safe. I see this is safe to deploy. Like, the task pass
Dom:Mhmm.
Andre:This doesn't change anything. This is like you review this in a much different way than when you're like, wait. Like, this is like adding a query. Like, this says actually doing something to the database. Then you're like, wait.
Andre:Hold on. Like, is this safe? Right? And this is an important part also. Like, you were you are reducing the scope of the changes that actually cause production changes.
Andre:Right? Like, I wanna be very careful when I'm looking at something that's gonna add a query to the database that is actually changing some use something the user sees, for example. And I don't need to look, like, that deeply. Like, I don't need to pay that much attention. Like, the the cost of review doesn't have to be that much when I'm just analyzing some refactor that by definition is like no op, like this won't change anything.
Andre:So the review fatigue there is smaller. But one important thing which we added almost from day one also in Twigg, which is also very important is ownership. Right? So, like, git I don't I think this is a GitHub specific thing, actually. This is not native to to Git.
Andre:GitHub has that, like, code owners, which usually sits at the repository root, and then you specify, like, people who can review directories. Right? In Twigg, this is this is like an this is a a native feature. So the idea is, like, directories they have you create an owners file, which is just like capital owners, and it's a list of usernames. And whoever is in there owns this directory in all the child directories.
Andre:So it's hierarchical. Right? And this way is that you're forcing people to like, okay, if something touches this part of the code, these people are owners. They have to approve this change. Right?
Andre:And this is how we share responsibility amongst ourselves. For example, there are three of us who are the core developers of Twigg. Mark is my brother. He owns the documentation part. He knows it better than I do.
Andre:So he's in the owner's file there. So this helps a lot with reducing the context switching and, like, not forcing everyone to remove to review everything. Right?
Dom:Right. Yeah. I like that a lot. Yeah. This this is this is great.
Dom:Let's talk about diff. Yeah. I'm so I'm so curious to well, first of all, I'm I'm very curious to to hear about Go and and before before the the the times lapse. Yeah. This seems to be a hard problem to solve.
Andre:Oh, man.
Dom:Yeah. Did you use did you use a library? Did you were you already versed into that that field? And anything anything interesting that you want to share about that?
Andre:Oh, yeah. There there's a lot to share about that actually. Because also that's like, when I first started, like, as I said, they started as a prototype. Right? And I was like, there's no way I'm gonna implement, for example, the UI part of showing side by side diff.
Andre:Like, that must be so hard. It's like one of those things that are like, I know I could do it, but I don't wanna do it. Like, it will be hard. So I started using a library for that and it worked okay. Eventually, when we started to, like, write more stuff, was like, okay.
Andre:I actually need to implement this. Right? There are there were two parts. First is and this one was actually harder, was if was with the rebasing. Right?
Andre:So the diff three algorithm. And this part is interesting because Go has an internal package, which does the the three way merge, which is what we used to do the rebasing. Right?
Dom:Oh, really?
Andre:Yeah. But it's internal. If like, I don't know why. Like, I don't know why it's not external. And then someone published this because there's a repository of, like, this.
Andre:All of this is doing is making then an internal file of the go internal standard library public. And that implementation is very good. And I was like, okay. Like, this is the the good part about open source. Like, I could just copy that, which is what I did.
Andre:And I I did some refactoring. But, luckily, I didn't have to dive in too much deep in in that part because I found that implementation. I saw one thing that surprised me a bit is I now see how this for example, the rebasing thing, which is like, yeah, you diff one side, you diff the other, kinda like diff like, you combine the diffs. The idea is like, if a this right side changed something that the left side didn't, then we want that change. If the left side changed something that the right side didn't, we want that change as well.
Andre:Like, you wanna grab all the changes. And if both sides change the same thing, well, that's when the conflicts happen. Right? And but this thing is not as algebraic as I thought it would be. Right?
Andre:And I found this the hard way. Like, when I was writing tests, I wrote, like, merges of three line files. Right? And the merge doesn't work in that way. Was like, how is this algorithm not realizing that like the right side only changed the third line and the left side only changed the first?
Andre:How can those two not be combined? And, yeah, it couldn't because the way the algorithm works is that it finds the largest sequence, and that's where it starts the diff from. Right? But, yeah, one one thing that took me a while to learn was this, that, like, it's not as like, it there is a lot of heuristics involved at the end of the day. That's why there are there's more than one merging algorithm.
Andre:Like, there's the diff three with like, there's the Myers algorithm, another one. Yeah. This this part was not as easy to to employ. Luckily, I I like, there was a lot. Like, I I could copy a lot of this this the merging part.
Andre:But what I had to do on the front end was to do this parsing to show, like, right side, left side, which once the diff is computed, is not too bad. It's like all the lines, they start with a space or a plus or a minus. But, yeah, it was kinda tricky to do.
Dom:Yeah. Go go in in all of its glory, I guess. I I did not knew there there was this internal package. This is crazy. Wow.
Andre:Yeah. Yeah. It's in I put this in the the repository. It's it's like a there's a diff package, and then there's an internal, and I wrote it. Like, this is a amazing implementation that, for some reason, is private, but now it's it's here.
Andre:So
Dom:Very nice.
Andre:Yeah.
Dom:Let's let's talk a little bit about well, a commit or a change set. I I don't know what to call that. But let's let's say let's say I'm I'm pushing something. So what is that something? You know, how how my changes to a file gets, you know, encoded into into whatever the server wants to receive.
Dom:What is what is the format there? Kind of
Andre:the Right.
Dom:The git blob or something like that. I mean, what what is what is the format of of Twig?
Andre:Right. Yeah. Good question. Because this was this was the most interesting part. Like, I learned so much doing this, Dom.
Andre:Like, with you, I have no idea.
Dom:I imagine,
Andre:yeah. Because it started that's the thing. Like, it started as like, yeah, it can't be too hard. Like, let me just and then eventually for example, eventually I re like, I fell into things, for example, oh, on the server, I wanna make, I don't know, this maybe submit something. The act of submitting should be transactional to, I don't know, changing a user username, for example.
Andre:Like, this is a dumb example, but I wanted to be able to combine those things. Right?
Dom:Mhmm.
Andre:I wanted there to be like a library. This is like one of priority. That, like, Twigg should be a library that the CLI uses, that clients use, and not primarily a CLI. Because then the server can embed this, use the library in the same way that the CLI uses. That pushed me to, like, okay.
Andre:Let's let's define, like, what the storage actually is. Right?
Dom:Mhmm.
Andre:And Twigg has it it has similar things that to get in a way that there are basically two things we store when it comes to the version control. One is the commit, and the other one is just blobs. And then sorry. Commit. Then there's the tree data, I call it, which is, like, metadata about a file or a directory, and then there's blobs.
Andre:So, like, the actual file content. And the storage layer was something I implemented, like, from from start from the start, which is, like, this needs to be efficient. So let's make this, like, delta compress whatever it stores. So even before writing anything of, like, actually saving commits, actually saving files was, like, I need an interface, like, implementation that is a key value store and that automatically delta compresses whatever you throw at it.
Dom:Okay. Yeah.
Andre:The way I did that was okay. Let's and and this is where I got inspiration from Fossil. Fossil is is a very cool version control. Most people don't know about that one, but it's used for developing SQLite.
Dom:Okay. Wow.
Andre:Yeah. Yeah. And and it basically store it's it's very recursive in the same way that Twig is. Like, we use Twig to develop Twig. And Fossil uses SQLite internally, and Fossil is used to develop SQLite.
Andre:It's used to version SQLite. Right? Like at some point you need some fresh manual build. Right?
Dom:Yeah.
Andre:And so Twigg, like, that's when I started, like, the the database. Let's, like, let's add a SQL layer, but then I wanted Twigg to work with arbitrary file sizes, and you can't have that in in SQLite. Right? Like, there there are there are column limits. They're pretty big, but there are limits nonetheless.
Andre:The solution I ended up using at the end Go was perfect for this, by the way. Like, actually writing this, I'm so happy I chose Go to write this on because it helped a lot, especially on this scenario, especially with, like, the forcing me to handle the errors was was, like, it is such a blessing from Go for these kinds of things. Because at this point, I was like, the one thing that is nonnegotiable for version control is that you can't lose the data. Right? It needs to like, this part has to be properly implemented.
Andre:Right? And so what I did is, okay, like, there is a SQL layer that, like, saves the keys and, like, the the commits and, like, the files and the metadata about the files, but the actual blobs are saved outside of the SQL layer. So it needs, like, a blob storage. So on the CLI, this is just a file on disk
Dom:Mhmm.
Andre:Which you basically just append to at the end. So you're like you you then then again, this is this is why this layer is only like this is a key value store that Twigg uses that could be used for anything else, but Twigg uses. But this like, it's depend it it was developed without thinking this will be used for version control. Right? And at this point, it's like when you're writing a blob, you write something to the the SQLite database, basically metadata about that blob, and then you stream the write to this blob storage, which is a file on disk.
Andre:Or on the server, it uses files on disks, and eventually, it spills to, like, an s three, like a blob to like a cloud blob storage.
Dom:Mhmm.
Andre:Right? And this is where, like, I I like this part of, like, okay. Like, we're done writing. We need to commit this transaction. How do we do that?
Andre:Right? And this is the the part that, like, go helped a lot as I was seeing with this error handling. Because then it's like, okay, first, actually writing to the file can fail. Go never allowed me to ignore that. Because there was like, when you use OS.
Andre:Fsync, for example, when you're syncing, that can fail too. And writing itself can fail. At the end, like, yeah, I implemented this layer. So this is, the storage layer. And then Twigg just uses that.
Andre:So when you you write a commit, it does, like, the diffing to to see, like, what changed in this direct like, in this working directory, which files changed. So then it's gonna it's gonna save in that storage. It's gonna save, like, file a dot txt, for example. It's gonna save that thing. And internally, right, the the database is using data compression to be efficient for storage.
Andre:And then it's gonna also store, like, the metadata about the files. Then it's gonna store the commits and, like, create a commit and store it, and that's it. That concludes, like, the what happens when you create a commit.
Dom:Nice.
Andre:When you're when Twigg is communicating with the server, it really just, like, reads those entities from the storage layer. So it first reads like a commit. So then there's, like, author, time created, message, those kind of things. And then it's just gonna send, like, okay, look. So here comes like a blob.
Andre:Then it sends a blob, the other side receives it, saves it, and so on. So when things are communicating, like, we read out those entities, send them through the wire the other side receives, saves them in their storage, which can be different also. Like they don't necessarily have to use the same storage, right?
Dom:Nice, Nice.
Andre:Yeah. This this was one of the coolest parts of like, maybe hardest, but also most interesting, I think, to implement.
Dom:Yeah. That's interesting for sure. So anything else that Go gives you that you did not expected? For example, I don't know. Are you are you using some hashing mechanism to in in, you know, concurrent concurrently and whatnot, you know?
Dom:Are you using any channels or or concurrent code in in there? Okay.
Andre:Yeah. Yeah. There I I think there are two things that come like, there are many. Right? Like, I I love Go.
Andre:Like, I really like it. And when I started this project, I I only like it even more every day. Nice. Two things that come to mind that illustrate this. One is how Go is batteries included.
Andre:Right? And so the first versions, they when I started testing with larger repositories, I saw, like, oh, this performance sucks. Like, this is taking forever to create a commit. What is going on? Right?
Andre:And Go, like has those tooling to like create like the pprof. Right. To like included profiling. And that thing is like so good, so good. Because we all know that I think like I had known this before, though, like, you should only try to improve things after you have some monitoring for that.
Andre:And now I saw that happening because I was like, I was sure for example, there was my my intuition was telling me like, oh, we need to add a caching here to this function. Right? And I was like, wait. Let let's do the profiling. And then it's like as as simple as running like go p professor something.
Andre:And then it runs a test. It gives you like the like a result saying like how many seconds is spent on each part of the code, which is just like wonderful. And that showed me like, Andre, like, you're wrong. You're stupid. Like that layer is not a bottleneck at all.
Andre:You should look here. Right? And that helped so much with improving performance where I actually should improve. Right? And the fact that that comes out of the box is just amazing.
Dom:Totally. Was there any allocation problem I can maybe Oh, yeah.
Andre:Also, also. Yeah. Yeah. Yeah. One was and this was totally like a skew issue.
Andre:Like, I I was so dumb about it. Like, I learned so much. Like, but this was the case where I was so dumb. Like, when I was doing this delta compression part, like, you event like, you to actually do the delta, you you first check, like, okay. What's the size of this?
Andre:Like, it needs to fit in memory. Right?
Dom:Mhmm.
Andre:And I was like, okay. This fits in memory. Okay. Now we actually put this in a slice of bytes. And then there was, like, a a library I found which implements the delta compression things.
Andre:Like, cool. And for some reason, I felt like, okay. Like, I need I need, like, a slice that can be big. So I'm just gonna do, like, make and, like, I don't know, a huge slice. Right?
Andre:And it wasn't apparent when you I looked at the couple layers, like like, it's obvious. Like, this hot path is creating a slice of, I don't know, megabytes of size. Right?
Dom:Right.
Andre:And it was just like allocating and deallocating it later. And this was like I was like, okay. Most of the CPU is being spent like deallocating memory, like, that's that's a problem. Right? And the the the profiler showed that, like, exactly where that was happening and if it then it was pretty easy to fix, right?
Andre:Another example you asked about like channels for example is when I implemented the CICD server, right? So the thing that runs jobs. At one point I was like, okay, like I need some way to cancel the jobs. Right? Because this is something we sometimes wanna do in the UI.
Andre:Like, stop running this.
Dom:Yep.
Andre:And at that point, I was like so happy that I that I chose Go also because like
Dom:The context.
Andre:Running, like, yeah, doing something that's like, there's a task running and you wanna like magically transport some information to where that code is running and just call like a close or cancel something, it was so easy to do with go. Right? Yeah. Like there was like a, there was a service struck that like runs the things. And so I just had to add, like, a channel for cancel for calling cancellation.
Andre:And then the server just had, like, one handler to, like, you wanna cancel this job, like, make a request here. That will be, like, magically routed through this channel and will end up, like, many layers down where the job is actually running. So that that was very good also.
Dom:Pretty nice. Pretty nice. So no regret at all to having having used Go?
Andre:Oh, no. Only, like, I I I'm everyday happier that I chose it. Another one, is also important is, like, Twigg has three dependencies. Right? Okay.
Andre:That's good. Yeah. It uses SQLite. So the driver for SQLite, and then it uses like a Docker client. And that they this is all for like running CICD jobs and the LXT client.
Andre:This LXT, like, it creates VMs, but but that's it. Right? And and sure. Some vents some dependencies were vendored in. So, like, it would be dishonest for me to not tell.
Andre:For example, the diff thing, like, I've vendored it in, so it's part of the code now.
Dom:Right.
Andre:But even though, you see, like, it's all these, like, small things. Right? Because Go has everything. Right? Like, the standard packet, like, the standard library for writing the the server is so complete.
Andre:Right? I didn't need to add anything in the way that the go community loves and is right to love by the way, which is like basically only use the standard library and it has more than enough. Like there's this edge case where I had to, for example, for the different part, like I had to get some library for that, like sure. But it's like so tiny and so contained and this is great for a lot of reasons. Right?
Andre:Even even, I mean, for running CI to, like, testing the the the code and to actually get it to run. Right? For so compiling it compiling the client for Mac, Windows, Linux, it's
Dom:Yeah.
Andre:They could just go install it and it works. So it's
Dom:very good. Suppose you are using the, you know, the modern modern c SQLite driver? No. Not a Seagull driver for SQLite. Yeah.
Andre:Oh, you you know your drivers. Right? Like, not every because there is that that trade off, right, that we need to choose. Yeah. Totally.
Andre:Yeah. I I didn't try the other one, by the way. I heard like, I'm curious about if you tried the other one. What I know is the non modern c one is, like, it harder to build, but
Dom:it's Well, the c o twice. Well Yeah. Will prevent you from from cross compiling. That that's a problem.
Andre:Right. Right. How how much faster is it? Because I saw online that that it's like it's up to twice as fast. Is that true?
Dom:Yeah. Think I think it's faster for sure because it's it's using it's using the the real c
Andre:Right.
Dom:You know, the SQLite library under the hood, in fact. So but, you know, I I I was curious. Yeah. That that that's a good question maybe to to continue. What you know, are you testing performance and and things like that?
Dom:Have you tried Twigg in a, I don't know, a decently sized project and whatnot? What what kind of performance test have you done?
Andre:Oh, yeah. Good question. I test, like, I I tested a lot of performance and, like, bank like, writing benchmarks initially, especially when I was seeing that the bottleneck was not clearly on the database, like, which was the case with the allocations, for example. When and I could especially see that in the the status command is the the dumbest one, it seems, but it's it's the most expensive one. Right?
Andre:It's like you're you're diffing everything. So you're right. You are at least statting all the files on disk to see if they changed, and in many cases, hashing them. And then reading the database to see what changed with respect to another one. Right?
Andre:And so while I was seeing a lot that the bottleneck was in other places, I kept, like, pushing fixing things fixing things. And at some point, I was like, okay. The the bottleneck is clearly C. Coli. And the thing we talked about, the driver was like, I wanna I wanna keep this this card in my hand to, like, if I ever want, like, a decent performance improvement, I can just switch drivers, and that should change a lot.
Andre:But I haven't used that one yet.
Dom:Nice.
Andre:And then I kinda stopped there. I was like, I think a lot of times we all wanna make things more performant, but that like doesn't move the needle in terms of like how good, like after some point it's like, it's fast enough. Right?
Dom:Right. Right. Right.
Andre:It's it's I was talking with, like, my my brothers, for example. One of them was like, I I don't understand what you're talking about. Like, this this is instant. And I was like, it's not Yeah. Yeah.
Andre:Totally. Totally. Instant. Right? Like like, it can't be more instant.
Andre:Right?
Dom:But not not only that, but, I mean, I would guess and this is coming from, you know, someone that that is building, you know, SaaS since twenty years. I would guess that your next focus will probably be on customer acquisition and whatnot. Because at the at the end of the day, we have we have talked about Twigg, the the open source, you know, thing or tool. I don't know. Program.
Dom:I'll call it what you want. Mhmm. But you are still you are still building a a business or at least you're you're trying to sell something with with the, you know, the the review and whatnot. Am I am I mistaking?
Andre:No. Yeah. You're you're a 100% correct. And and that is our our our focus now. So it is like, it is open source.
Andre:We chose to do it open source. Anyone can run, like you can run it locally, use it locally. But yeah, we want to make it like we want to make a model similar to what GitLab uses, for example. Right? They they they have, like, enterprise customers that they use it, and then GitLab hosts the server for them.
Andre:This is a path we we wanna go to. What we have now, you asked about, like, tests and stuff. Like, we made a bunch of tests, like, locally to, like, personal projects. But then and it's this has been almost six months now, I think. We have partnered with two companies that are our clients and that are using Twigg in production today.
Andre:So they use it for their day to day development.
Dom:Okay. Wait. Wait. Wait. Wait.
Dom:Wait. I it's it's already one hour. Do you have a couple of more minutes? Because this is this is very interesting.
Andre:Oh, I have. I I have a long time. Like, I I'm not in a rush at all, and I'm enjoying this. So so we we can
Dom:Let me ask you, how was it how was the adoption? I would guess that they were probably using Git.
Andre:Yes. Yeah.
Dom:Okay. So how did you brought Twigg to the team? Was there any friction? How how was the reaction?
Andre:Yeah. This is where I cheated a bit. Like, I cheated a lot. Right? It which is, like, are they are they clients?
Andre:Yes, they are. They are using day to day, these two companies. And it's working great. And God, it's been so good that like we we saw like like feature requests coming from actual users and that helped so much. And we caught bugs with that.
Andre:Right? I mean, the the clearest one is, like, from day one when we onboarded this first customer is, they're like, okay. Where do I sign in? I was like, yeah. Click here.
Andre:Sign in with Google. And they're like, oh, we use Microsoft. And we're like, oh shit, we haven't added Microsoft yet. Right? Yeah.
Andre:That one is clear, right? And maybe it would have taken us much longer to see that if it weren't for the customers, like the customers actually using. But when I say I'm cheating is like they are customers because like we're doing contractor work for them, right? So this was like, wanted to hire SWIS, like software engineers. And I was like, what are you building?
Andre:Right? Oh, I need to build this platform. I was like, I can help. Like, that seem that doesn't seem too hard. You like, you have the budget.
Andre:How about you pay us for the contractor work,
Dom:but you Oh, you are the team.
Andre:Yeah. Yeah. Exactly.
Dom:Okay. Okay. Okay.
Andre:And they hired but they hired others as well. Was like, this this was part of the deal. It's like, you need to hire at least one person.
Dom:Right.
Andre:Because then we have, like, an unbiased user. Right? And we we've helped with let's say like regular WeWork, so just writing a crud app or stuff like that. And they use our platform and that's how we're funding the project by the way. Because we need to pay our bills and we haven't raised, when we don't, I don't think we plan to raise at least for now, but this is more than enough to pay for our bills and to get these users.
Andre:So that that's what we've And been definitely, like, the next step is to acquire. Like, we really want a user that is just a user and that we don't we don't have to, like, either you use it or I won't code for you. Right? Because that that's what I say, like, that was cheating. Right?
Andre:It's like they're they're not using Twigg really because of the the benefits that I believe we the the platform provides, but for other reasons. Right?
Dom:Yeah. Yeah. Because if if we are frank between each other, I've I've been looking at Jujitsu for a long time. I've been it's on my radar. It's there.
Dom:Mhmm. Each each time I'm saying to myself, I should try this thing. I never never really done. I mean, what I'm trying to say is that trying to replace Git is a major, you know, major task. But on the other hand, this is the this is probably the perfect time because like we were saying at the beginning, there is something.
Dom:There is something going on. I'm sorry, but there is something going on with guitar, but at the moment, there is something going on with git. And not only because the LLMs and whatnot, I I I think yeah. Yeah. May maybe there there's something there about about the the small changes returning to trunk base.
Dom:I know that, you know, people that are very, very heavy on test driven development prefer not using branches and PR and whatnot. I mean well, PR, yes. But I mean, they they basically just just use a main branch.
Andre:Right.
Dom:So, I mean, yeah, there there's there's something there, but I can imagine that, wow, the the it's it's the Mount Everest that you will need to climb because it's a hard sell.
Andre:Oh, 100%. And we we saw we saw that, like, especially when we try we saw, like, wait, like, there is friction. There is a lot I mean, there's friction when you change the UI, so of anything. Right? So Yeah.
Andre:Yeah. Yeah. Changing the version control, there's a lot of friction. The first thing we did was and and this changed the the conversations completely is we added a Git mirror support. So you can basically, like, you use Twigg.
Andre:Whatever gets submitted is pushed to Git. So that can be GitHub, GitLab, whatever Git server. And this changes so much because at the end, it's like, we don't have to ask someone like, do you want to, like, fully commit to changing our version control? It's like, do you wanna test this? See what it looks like?
Andre:And if you don't like it, if something goes wrong, you just stop using and things are already in your Git server. Right? This changed a lot. But, yeah, like, there there are there's still friction even with that. Right?
Andre:And, honestly, I'm I'm open for suggestion for tips of how to fix that. What I'm What we're thinking now is there are probably certain niches like what you said about TDD folks that are suffering this pain maybe in the similar way that I was when I was back to working with PRs, right? And that are more open to looking for something different. And what you mentioned about, what we're seeing with how development is changing with AI driven development, Like, maybe there are niches which are suffering even more than others. But, yeah, changing, like, changing this kind of thing is is is hard.
Andre:But Yeah. One thing Because
Dom:oh, yeah. Go ahead. I don't know. Go ahead.
Andre:Oh, the only thing I I I think when when I'm starting to think this thing is like, I would argue that changing a database is harder because you are actually changing what you use in production, But people have changed databases.
Dom:So Oh, yeah.
Andre:I don't think it's I don't think it's impossible, but it yeah. It's definitely a a challenge.
Dom:Yeah. Lots of people changes for Mongo in in 2014 and ran quickly in 2018 to Postgres
Andre:Yeah. At some point.
Dom:But but I I I I really I really well, first of all, I like that it's go. My my interpreter entrepreneur. My entrepreneur at will will speak now. Restarting from the beginning of the of the conversation, you were saying that this kind of probably solve problems in bigger organization. So maybe your first target, which is very hard to to grab, is probably the bigger org that do not have the, you know, Google's and Facebook, you know, money to build their own tools internally, but would would because yeah.
Dom:Because the the the smaller developer yeah. That that that would be that would be our hard sell for now, I think, because they probably don't have the pain.
Andre:You yeah. You're a 100% right. And this is the tricky part. Mhmm. Because I do I do see that the the pain the pain that I'm talking about, the pain of the development itself with the with what happens with this, like, PR model versus the the stacked commits and small changes in trunk base.
Andre:Like this pain is higher the the the bigger the client is. But at the same time, like selling to bigger enterprises is harder. Right? Convincing, like, if you wanna convince, like, a big, like, corp to to use it, like, this is a like, the sales cycle takes forever. Right?
Andre:So that that is a challenge.
Dom:Yeah. Totally. So do do you do you receive any kind of good feedback so far, you know, from from your Reddit post and whatnot? Is is there is there anything anything going on? Are you looking for any help?
Dom:How you know, what what can we tell the the listeners if if they want to, you know, to check Twigg?
Andre:Right. Yeah. Yeah. Thank thank you so much for asking. I I'm so bad at marketing that was was not gonna mention any of that.
Andre:You can see that like sales business part is not really my forte. But yeah, no, feedback I've gotten is like mostly positive. Like a lot of people are interested, right? Because this is just like, I talk with some friends that like Git is like gravity almost. Like no one complains about gravity, right?
Andre:Gravity is what it is. Right. Right? It's like, it's part of the universe, right? Just in the same way that Git is.
Andre:So when something comes up, which is like you and we are like a pin like we've chosen not to to build something compatible with Git. Like, we want, like, a compatibility layer, which is like this this mirror to help the transition, but we don't want it to be compatible. Mhmm. People get interested and wanna see what it's like, but there is friction of, like, replacing this in in their workplace, for example. But what I would ask, like, one way if if for anyone listening is, you can you can check out, like, our website is Twigg with two g's, twigg.vc.
Andre:And I joke that v c always stood for version control. It's never about venture capital. Those guys are wrong. You can create a there's a free account. So this is our hosted instance, and it's very easy to test.
Andre:Like, the so you can just, like, sign in. It takes, like, ten seconds. You just click sign in with Google or with Microsoft now. Test it. See what you think of it.
Andre:And what what what we are looking for now is so a design partner, so some someone we can work closely with to, like, what are the features that, like, we need to prioritize that will work best for you. And the pain that that they were looking for is, that people are suffering with, for example, the development workflow to like, they are having, I don't know, have to deal with a lot of merge conflicts, for example. This is what happens when you're working with big changes submitted all at once, for example. Yeah. Or with like, there's a big bottleneck now in the review phase because we're writing so much code with AI.
Andre:That is a place where I think Twigg helps a lot. Right? So, yeah, if if anyone listening is interested, like, hit me up. Like, you can we have a Discord community for you to ask questions. We are very open, and we're looking for people to collaborate with.
Andre:So if you're in some position to choose that and you wanna test it out, and as I said, there is a Gitmirror. So the switch and back cost is zero. You just stop using if you don't like it. Like, yeah, you can call me on on Discord or or email me as well. Like, you should all all should be easy to find our on our website.
Dom:Very nice. Yeah. We will have all the links in the show notes. So I I think I think that's great because now well, it could can also mean that teams will will not be afraid to to push on on Fridays and wow.
Andre:Yeah. Yeah. That
Dom:that is would be a huge change.
Andre:Yes. Yes. I think that yes. I think that is a good, like, success criteria, and we push on Friday too. So I think we are we are work walking our talk.
Andre:So
Dom:Yeah. Totally. Alright. Alright, Andre. That that was that was very interesting.
Dom:You know, come back come back to the show in in, like, six months or so when you have something else news to to communicate. It's always it's always interesting to to see the project project go. I I like the domain extension, by the way. So it's really nice.
Andre:Awesome. Glad you liked it. And No. I hope to be back. Let let's schedule the the next one.
Andre:This was this was awesome. It was awesome to get to know you. Awesome to talk about this. Like, I'm I'm obsessed with the the project, so I can talk about it for the whole day. So, yeah, let's definitely schedule the next one.
Dom:Very cool.
Creators and Guests
