I personally feel that:

1) Git is fine

2) I would not want to replace critical open source tooling with something backed by investor capital from its inception.

Sure, it will be “open source “, but with people throwing money behind it, there’s a plan to extract value from the user base from day one.

I’m tired of being “the product”.

Critical open source tooltips by should spring from the community, not from corporate sponsorship.

▲ farouqjalabi 6 hours ago | parent | next [-]

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.

▲ s1mplicissimus 4 hours ago | parent | next [-]

"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

▲ chrysoprace an hour ago | parent | prev | next [-]

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

▲ BatteryMountain 2 hours ago | parent | prev | next [-]

So.. worktrees?

▲ toenail 6 hours ago | parent | prev [-]

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

▲ arnvald 5 hours ago | parent | next [-]

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

▲ _fizz_buzz_ 5 hours ago | parent | next [-]

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.

▲

BatteryMountain 2 hours ago | parent | next [-]

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.

▲

stingraycharles 2 hours ago | parent | prev [-]

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.

	▲	sassymuffinz 2 hours ago \| parent [-]
		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.

▲ user34283 5 hours ago | parent | prev | next [-]

That has been implemented 10 years ago:

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

▲ skydhash 2 hours ago | parent | prev [-]

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

▲ nacozarina 3 hours ago | parent | prev | next [-]

‘Embrace, extend, extinguish.’

	▲	cindyllm 3 hours ago \| parent [-]
		[dead]

▲ rimliu 6 hours ago | parent | prev [-]

and worktrees too.

	▲	doublesocket 3 hours ago \| parent [-]
		Which Claude literally uses.

▲ IshKebab 6 hours ago | parent | prev | next [-]

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.

▲

k4rli 6 hours ago | parent | next [-]

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.

	▲	theappsecguy an hour ago \| parent \| next [-]
		I would urge you to take a look at the founding team here, I doubt that they vibe coded this tool.
	▲	dare944 3 hours ago \| parent \| prev \| next [-]
		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.
	▲	weedhopper 4 hours ago \| parent \| prev [-]
		Rust! it’s written in rust and not javascript!!!!

▲

DonThomasitos 5 hours ago | parent | prev | next [-]

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

16M$ VC money saved.

▲

IshKebab 2 hours ago | parent | next [-]

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

	▲	_fizz_buzz_ an hour ago \| parent [-]
		If only 100 people in the world are using this language, who are you even merging code with, lol.

▲

user34283 5 hours ago | parent | prev [-]

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?

	▲	hrimfaxi an hour ago \| parent \| next [-]
		In my experience, yes. It has done a great job of choosing which changes should be integrated based on context in the repo, too.
	▲	speedgoose 3 hours ago \| parent \| prev [-]
		Not the person you responded too, but in my experience the answer is a big yes.

▲

hk__2 6 hours ago | parent | prev | next [-]

> 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

▲

a-french-anon 6 hours ago | parent | prev | next [-]

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).

▲

skydhash 2 hours ago | parent | prev [-]

> 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).

▲ dethos 4 hours ago | parent | prev [-]

Bingo