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.

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)

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.

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

Comments URL: https://news.ycombinator.com/item?id=45418648

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45346137

Points: 3

# Comments: 1

For the deadnaming comment, it wasn't out of disrespect, but when referring to an email chain, it could otherwise be confusing if you're not aware of her transition.

I wasn't sponsoring hg-git, I wrote it. I also wrote the original Subversion bridge for GitHub, which was actually recently deprecated.

https://github.blog/news-insights/product-news/sunsetting-su...

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.

It also is a testament to the backwards compatibility of Git that even after 17 years, most of the contents of that book are still relevant.

However, I don't think you would want to use the SHA, since that's somewhat meaningless to read. You would probably want to expand ID to `git describe SHA` so it's more like `v1.0.1-4-ga691733dc`, so you can see something more similar to a version number.