schacon

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)

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.

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

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

If this is something you're interested in, you may want to try the patch-based review system that we recently launched for GitButler: https://blog.gitbutler.com/gitbutlers-new-patch-based-code-r...

"One particular aspect that often gets left out of this creation myth, especially by the author of Github is that Mercurial had a prominent role." implies to me that Hg had a role in the creation of Git, which is why I was reacting to that.

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

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.

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.

Good pull. I was wondering if that was a true statement or not. I am curious if Linus knew about that or made it up independently, or if both came from somewhere else. I really don't know.

Ah yes. It was pretty cool that when Peepcode was acquired, Pluralsight asked me what I wanted to do with my royalties there and was fine with me waiving them and just open-sourcing the content.

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.

You can use smudge and clean filters to expand this into something on disk and then remove it again before the hash computation runs.

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.

You can probably setup smudge and clean filters in Git to do keyword expansion in a CVS-like way.

You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.

I think it's more interesting to build tooling that helps with the core problem rather than try to change people's attitudes. The problem imo is not that people are lazy, but that the review tooling is not good at the problem set of large changes that need to be introduced atomically.

Even if a change is not enormous, it can still be difficult to grok the context of a change when it's all squished together. Reviewing a series of smaller changes with good context messages is just mentally easier and technically simple (plus ends up with better commit messages for future context).

I've seen Butler Requests come in via our internal usage where the unified diff is still fairly small, but it's much easier still to review it properly when it's broken up into semantically grouped changes with good commit messages.

The brand newest version of Git has a new `git backfill` command that may help with this.

https://git-scm.com/docs/git-backfill

If you want us to cover something on Bits and Booze, just let me know! :)

These days if you do a blobless clone, Git will ask for missing files as it needs them. It's slower, but it's not broken.

This is fascinating, I didn't know they did this. This is actually not using the built in functionality that Git has, they use a shell script that does basically the same thing rather than just advertising the bundle refs.

However, the shell script they use doesn't have the bug that I submitted a patch to address - it should have all the refs that were bundled.

The `--branches` option will work with how git works today. If my patch gets in, future versions of Git will be better with `--all`.

To try this feature out, you could have the server advertise a bundle ref file made with `git bundle create [bundle-file] --branches` that is hosted on a server within your network - it _should_ make a pretty big difference in local clone times.

You can see basically what part of the communication is by running `git ls-remote` and see how big it is.

Yeah, it basically has to advertise everything it has, so if you have a lot of references, it can be a quite large exchange before anything is done.

Damn you!

I did find it a little funny that my patch was so small but my commit message was so long. Also, I haven't successfully landed it yet, I keep being too lazy to roll more versions.

I should do another article on the best aliases, because this is a great one. I want it just because I want to do the Arnold voice every time.

Now I want to do: `git to-da-choppa`

I'm curious what you mean. I've been practicing trunk based development since 2011[0] and all of these config settings help that flow. Arguably you don't want the rebase thing, but otherwise I can't imagine what you think here would not apply.

[0] https://scottchacon.com/2011/08/31/github-flow/

I really wanted to add this (I linked it in the last paragraph) but I really wanted to keep the recommendations globally applicable in vanilla git. Delta is awesome though.