My impression from GitHub was always that it was nice to have someone else host Git repositories for free, and that the "added value" (the Web view, the user management, the CI, the Wiki) were all made by dilettantes: poor quality, mostly useless, never doing the right thing.

These people seem to think that their "added value" was the selling point of their product... they appear to believe that some bad things are actually good and desirable, like, for example:

> Heck, it could be argued that development in teams is less social than it was when version control was centralized.

> But what if coding was actually social? What if it was easier to for a team to work together than it is to work alone?

This reeks of open-space floor office plan all over again! When some HR managers decided that programmers need all to sit in the same room the size of a basketball court and that would somehow help them work together better...

Programming is absolutely an individual activity first, where communication helps, but in order to be helpful the communicating parties have to have an initial internal process that refines the messages s.a. not to waste the other party's time. In practice, productive communication may happen once a day... up to once a week maybe? Maybe even less frequently? Git, as it is, is perfectly fine for this.

> Ok, that’s the simple case, pretty straightforward. However, GitButler can also do some pretty cool things that Git either cannot do or struggles with, namely:

> Having multiple active branches that you can work on in parallel.

I'll check out the same Git repository in different directories and will have this ability... maybe also add the second checkout as a remote to the first... but the number of times I've done it in two decades of working with Git is... maybe two? This is an extremely unusual need. I think, I've done this when migrating from multiple repositories into a monorepo and I had to somehow reorganize the history of multiple repositories so that it would make sense together. Definitely not a task for every day, not even every year.

The whole follow-up demonstration of parallel branches is just... Why on earth would I ever want to do that? Why would I want to work in such a way that I commit changes to different branches at (roughly) the same time? It's kind of like stashing changes, but, stashing is the byproduct of "bad planning": I wanted to do one thing, and accidentally did another... oh well, let's save the change somewhere temporarily! But, ideally, I want this to happen as little as possible. Not because it's inconvenient to deal with stashed changes, but because I will very quickly lose track of what goes where, why any particular branch exists etc.

Similarly, for the stacked branches: I absolutely don't want this functionality to exist... if it was already in Git, I'd request that it never be used. This complicates the mental model of what is even possible in the repository and creates some nightmare fuel scenarios: what happens if you stack them sequentially? What happens if you stack many branches on the same branch, and then want to rebase one of the stacked branches? What happens if you rebase the branch on which other branches are stacked? What happens if you delete the branch on which other branches are stacked? Does the stacked branch have to exist in the local checkout, or could it come from a remote?

It's absolutely the case where simple is better (I'd never imagine I'd call Git simple, but here we are).

I can't imagine what the workflow of people who want these changes must look like. I can't imagine why would anyone want to copy that kind of a workflow.

We've raised $17M to build what comes after Git