Ah, I see. You missed the part where that was funny.

I would like to take this opportunity to kindly inform you that I wrote that post, as I write all of the blog posts on our blog (and everywhere else I write). You will never see something with my name on it that was written by AI. Thanks.

Actually, it is. We're currently leading a conversation among several players in this space to agree on a metadata standard that helps make attaching, collaborating on and transmitting information like this simple, extensible and scalable.

Keep an eye on our blog to see how we're doing this, and how we're doing it in a way that hopefully the entire community joins us in a way where we're not all reinventing the same wheels.

I'm trying not to comment on too many of these, but this one is interestingly wrong to me, so why not indeed?

GitButler came about many years ago because I have been using Git for almost the full 20 years of it being around and I thought there could be a better way to do the things it's trying to solve for us. I want version control to do more for us, easier, faster and smarter. Git is still pretty dumb. Plus, now, everything in the dev workflow is changing - it's an interesting problem to think about what a _great_ toolset for how we'll all soon be developing software will be.

As a _single_ example - agents can't use interactive editors, yet _so many_ of the powerful parts of Git absolutely _require_ it. Agents can't interactively rebase, meaning they can't very effectively squash, amend, reword, reorder, absorb. They can't very easily interactively add. They are middling at best when it comes to stacking branches. Git is designed to send patches over email and agents are not concerned with that.

I would love to debate all of the lessons learned about the history of Git, but I was around for all of that. I know why Git was started, I know what it was meant to do, I understand how it's evolved. I still think there are a lot of interesting things that we could have in our change control tooling and Git is not the perfect solution.

Nearly everyone in this thread suffers from the same basic local maxima blindness that you do. Git is great, GitHub made it more valuable. But maybe the answer to the papercuts we've constantly been dealing with for decades isn't faster horses. (To, you know, mix metaphors)

There does seem to be a lot of jaded pessimism this morning (buck up, fellas!)

I watched a bit of the gitbutler video and I liked the ideas, multiple/stacked branches. It felt like a genuine/natural extension of git concepts.

Sortof like Typescript vs JavaScript, I worry that the payoff of adopting something like Gitbutler would require navigating a lot of janky integrations with the rest of my tooling and training of the team.

I myself have always resisted mastering the git command line because JetBrains' git tooling is so nice, and abstracts just the right bits that I haven't had the need. I'm not opposed to switching to command line, but that 3-way git merge tool that JetBrains has is so good and I'd hate to lose it.

Honestly, I predict the world and its networks and developers are going to start cloistering and close themselves off as the AI training panopticon is getting nasty.

It would be great for Gitbutler to abstract true decentralized version control by offering decentralized/self-hosted feature parity with GitHub and remove vendors like them from the picture. I'd pay recurring seat licenses for something turnkey that I could run privately and securely.

I bet I should've had that coffee first :)

You use git at a level beyond mine; I've been fumbling with it for maybe 2/3 of the time you've been actually using it, so I appreciate you even taking the time to respond.

I think what gets me is that according to the article, GitButler is designed "for the GitHub Flow style" of development. git isn't limited to one flow, why should its successor be? Git didn't need $17M funding (and the strings that come attached to that) to change the world. Why should its successor?

But yeah I should've had that coffee first, so thanks for the respectful push-back and I hope the rest of the community appreciates it.

Why is GitButler still using Git if Git is the problem?

> As a _single_ example - agents can't use interactive editors, yet _so many_ of the powerful parts of Git absolutely _require_ it. Agents can't interactively rebase, meaning they can't very effectively squash, amend, reword, reorder, absorb. They can't very easily interactively add. They are middling at best when it comes to stacking branches. Git is designed to send patches over email and agents are not concerned with that.

Why aren't these just patches to Git itself? Or a fork of Git. You're layering tooling on top instead of fixing the foundations? You say stop layering? But you're clearly still using Git because you're calling it GitButler. You're another layer, like jj and like GitHub's UI.

Git is awesome in lots of ways. As a data storage layer and as a transport protocol, it's pretty great. The porcelain was built for a different era and is slow to adapt. Originally, Git was meant to just be these primitives and everyone was supposed to write their own "porcelain" or SCM on top. We're doing that and then some - creating new standards for more metadata, real time communications, built in review, etc. If anything, we're going back to the original point of git and doing what Linus wanted other people to do in the first place - write a good SCM for their workflows on top of the foundation he started.

Just to clarify (and we do say this when you run `but setup`), the `pre-commit` hook is needed because of the way that we manage commits - we allow for multiple parallel applied branches, which Git cannot do. The way we accomplish this is to maintain a hidden 'megamerge' commit (as JJ would say). All Git commands work fine the way we're doing it except 'git commit', which is not aware of our operating model and will commit on top of our megamerge, which is problematic. So we install pre-commit to protect against getting yourself in a poor situation by using both Git and GitButler interchangeably.

It's not difficult to "escape" - using `git checkout` will tear everything down properly - that's the only task of the `post-checkout` - to determine that you want to go back to using vanilla git commit tooling and remove our shims.

We also don't have a prepare-commit-msg hook - our commit tooling will inject an extra Change-Id header (of the same format and interchangeable with Jujutsu) but that affects nothing that vanilla git cares about.

this is bad developer UX ( in my opinion). Please reconsider . I lost interest the moment I was not able to commit using normal git commands.

  ⎿  Error: Exit code 1

     GITBUTLER_ERROR: Cannot commit directly to gitbutler/workspace branch.

     GitButler manages commits on this branch. Please use GitButler to commit your changes:
       - Use the GitButler app to create commits
       - Or run 'but commit' from the command line

     If you want to exit GitButler mode and use normal git:
       - Run 'but teardown' to switch to a regular branch
     … +5 lines (ctrl+o to see all)

but was not installed ( I installed the mac app ) .

I still haven't uninstalled the app and will try to figure out the working model.

Also please offer some skill file or a text I can add to my CLAUDE.md / AGENTS.md so that when I ask claude to commit , it will go through gitbutler...( edit: looks like it is there, but the discovery is hard ) .

We will remove the hook constraint as soon as we complete this https://github.com/gitbutlerapp/gitbutler/issues/11866

For the Claude question, the CLI ships a skill, set it up with `but skill install`.

I hope this helps

All I did was install GitButler via my OS's package manager, and open a local repo via the GUI.

And I saw these malicious (pre-commit) git hooks installed by GitButler, without any confirmation, or prompt seeking my approval.

I'm sure you folks will come up with a "technical explanation" or some "legal-marketing language" to cover up for this — but in my book — redirect `git commit` to `but commit` is dishonest and unethical.

You keep using the word malicious, what do you mean? What is the malice?

Yeah it feels malicious if it doesn't tell you it's going to do that, like a sneaky lock-in

Silently replacing Git with `but`.

Hey, this is Scott - the guy in the photo who wrote this post. AMA.

I've been using gitbutler since 09/24. It was the first git GUI I preferred over the command line. Being able to separate local changes into separate branches, drag missed changes into a past commit, etc. made tidy development so much easier. It is a great tool and the hate here is wild. However, I find it less useful when agents code for me. The surgical changes GitButler made so easy became less relevant as agents touch so many files at once. Have you found the same? Whats your vision for how GitButler will make agentic coding better in the way it did human coding? Does it move away from the UI you have now to something else? Does the UI get relegated and it becomes a tool the agent controls? (I liked the agent integration but it didn't feel like an improvement over using codex/CC so I went back to using them directly)

I'm seriously funny...

GitButler handles all of this pretty automatically, if you don't want to deal with the Git gymnastics needed here.

https://blog.gitbutler.com/stacked-branches-with-gitbutler

This is all fairly speculative, but I didn't get the impression that Monotone was a main inspiration for Git. I think BitKeeper was, in that it was a tool that Linus actually liked using. Monotone had the content addressable system, which was clearly an inspiration, but that's the only thing I've seen Linus reference from Monotone. He tried using it and bailed because it was slow, but took the one idea that he found interesting and built a very different thing with that concept as one part of it is how I would interpret the history between these projects.

Linus was definitely aware of and mentioned Monotone. But to call it an inspiration might be too far. Content Addressable Stores were around a long time before that, mostly for backup purposes afaik. See Plan9's Venti file system.

I'm curious why you think hg had a prominent role in this. I mean, it did pop up at almost exactly the same time for exactly the same reasons (BK, kernel drama) but I don't see evidence of Matt's benchmarks or development affecting the Git design decisions at all.

Here's one of the first threads where Matt (Olivia) introduces the project and benchmarks, but it seems like the list finds it unremarkable enough comparatively to not dig into it much:

https://lore.kernel.org/git/Pine.LNX.4.58.0504251859550.1890...

I agree that the UI is generally better and some decisions where arguably better (changeset evolution, which came much later, is pretty amazing) but I have a hard time agreeing that hg influenced Git in some fundamental way.