Gitbutler is backed by git. Gitbutler is essentially just ui for git which also allows you to have multiple branches. It isn't meant to replace git.

"Backed by" as in "running git under the hood", not as in "supported by the git organization". I'd probably use "powered by" in this case to avoid confusion

Not quite - it totally takes over your branching strategy and locks you into GitButler.

So.. worktrees?

What does that even mean? Multiple branches is a git feature.

I think it means parallel branches. Normally in git you can use one branch at a time. With agentic coding you want agents to build multiple features at the same time, each in a separate branch

Can agents not checkout different branches and then work on them? It's what people also do. I have a hard time to understand what problem is even solved here.

Yes, this is the obvious solution. Multiple agents working on multiple features should use feature branches.

Can’t believe how this whole AI movement seems to want to reinvent software engineering, poorly.

Their goal is not to give us a better tool, it's to get us to think our old tools are rubbish so we give them money instead.

to be entirely fair while git is getting better, the tooling UI/UX is still designed with expectation someone read the git book and understood exactly how it works.

Which should be basic skill on anyone dealing with code, but Git is not just programmer's tool any more for a long time so better UI is welcome

Has that ever been achieved in software/dev industry?

claude can use worktrees.. so if you have a system with say 10 agents, each one can use a worktree per session.. no need to clone the the repo 10 times or work on branches. Worktreeees.

That has been implemented 10 years ago:

  git worktree add -b feature-2 ../feature-2

Even before git has the worktree feature, you could just clone the repo again (shallowly if it’s big).

Sooooo git worktree. It's exactly that. One repository dir checked out in different places with different branches.

Not quite, Gitbutler allows you to apply multiple branches to the code base at once. With codebases you will have multiple code bases not one.

for example: It allows me to test coworkers branches with mine without merging or creating new branch.

It has many features that makes it super easy to add patch to any commit in any branch

Seconding others here, what you're bringing up as distinct features of Gitbutler seems to just be stuff git can do.

- One local copy of a repo with multiple work trees checked out at once, on different branches/commits? Git does that.

- "Add a patch to any commit in any branch" I can't think of a way of interpreting this statement (and I can think of a couple!) that isn't something git can do directly.

Maybe it adds some new UI to these, but those are just git features. Doesn't mean it's a bad product (I have no idea, and "just UI" can be a good product) but these seem to be built-in git features, not Gitbutler features.

Yeah ur right, Gitbutler is just UI that makes it easier to do the mentioned stuff.

> for example: It allows me to test coworkers branches with mine without merging or creating new branch.

How is that not supported by worktrees? You are aware, that you can checkout commits?

...I don't think you actually know how git works if you think that's the thing you can't do with git.

Does it checkout different branches at the same time, provides an in memory representation to be modified by another API, or does it to multitasking checkouts. The first thing is already natively in Git. I guess the others are innovation, although the second sounds unnecessary and the third like comedy.

and worktrees too.

Which Claude literally uses.

Git is fine. I would like something better than fine though, especially for dealing with rebase/merge conflicts where I would say Git is mediocre.

What about a vibecoded replacement with emojis and javascript?

Surely $trillion "ai" thing can generate a better solution than one Finnish guy 20 years ago.

I would urge you to take a look at the founding team here, I doubt that they vibe coded this tool.

Rust! it’s written in rust and not javascript!!!!

Lol. Unfortunately VCs and ever-so-ernest founders are impervious to irony. Best to just let them get their grift on and just be happy it isn't your money they're boondoggling.

> Git is fine. I would like something better than fine though, especially for dealing with rebase/merge conflicts where I would say Git is mediocre.

You can define your own merge strategy that uses a custom executable to fix conflicts.

https://stackoverflow.com/a/24965574/735926

„Claude, merge these branches and resolve conflicts. Ask me if unclear.“

16M$ VC money saved.

So far I have not let AI work with git, because I preferred handling version control myself.

Does it work well for resolving merge conflicts in your experience?

In my experience, yes. It has done a great job of choosing which changes should be integrated based on context in the repo, too.

Not the person you responded too, but in my experience the answer is a big yes.

I'm sure that will go well for my formal model in a language that about 100 people use...

If only 100 people in the world are using this language, who are you even merging code with, lol.

Some of the other people?

> especially for dealing with rebase/merge conflicts where I would say Git is mediocre.

It seems like everyone that hold this opinion want Git to be some magical tool that will guess their intent and automatically resolve the conflict. The only solutions other than surfacing the conflict are locking (transactions) or using some consensus algorithm (maybe powered by logical clocks). The first sucks and no one has been able to design the second (code is an end result, not the process of solving a problem).

> It seems like everyone that hold this opinion want Git to be some magical tool that will guess their intent and automatically resolve the conflict.

Absolutely not. There are plenty of fairly trivial solutions where Git's default merge algorithm gives you horrible diffs. Even for cases as simple as adding a function to a file it will get confused and put closing brackets in different parts of the diff. Nobody is asking for perfection but if you think it can't be improved you lack imagination.

There are a number of projects to improve this like Mergiraf. Someone looked at fixing the "sliders" problem 10 years ago but sadly it didn't seem to go anywhere, probably because there are too many core Git developers who have the same attitude as you.

https://github.com/mhagger/diff-slider-tools

> where Git's *default* merge algorithm gives you horrible diffs

You are saying it yourself.

Saying what? Defaults matter. The fact that other people are doing their best to improve Git's mediocre defaults doesn't excuse it.

I doubt you would defend any of Windows' poor defaults because there are tools to fix them.

Well, yeah, but Git is basically UNIX/POSIX or JPEG. Good enough to always win against better like Plan 9 or JPEG XL (though I think this one may win in the long term).

> but with people throwing money behind it, there’s a plan to extract value from the user base from day one.

They'll start injecting ads in your commit messages, forcing you to subscribe to a premium plan.