3 ms·

That's simply untrue. Bzr was dog slow on repos with lots of history. It had lots of early users and support from hosting services like Launchpad, Savannah, and

That's simply untrue. Bzr was dog slow on repos with lots of history. It had lots of early users and support from hosting services like Launchpad, Savannah, and SourceForge. I'm certain that everyone didn't migrate to git because of hype. I mean, it's not credible to say the Emacs team stopped using it because it wasn't fashionable. There were lots of DVCS projects at the time, like arch, darcs, and dcvs. People were running all kinds of experiments to explore the Cambrian explosion of new ideas. Some of them did some things better than git, but git handled most of those things reasonably well and it was fast. We all mostly ended up on git because it was generally the better option. It earned the hype, but the hype followed the adoption, not vice versa.

chx 2y ago
So in exchange for a little speed we are stuck with one of the most user hostile tools out there. That's not the deal I would have wanted to make. The interface is atrocious as some switches change completely what the command does -- this was partially acknowledged and fixed in git switch but there's so much more, it loses work way too easily and some of the concepts are near impossible to grok. (I did learn git eventually but that doesn't mean I like it. It's more of an uneasy truce than a friendship.)
- kstrauser 2y ago
  It wasn't a little speed. Other options were many times slower. I just renamed a large subdir in a large project. `time git status` took 41ms. That kind of speed lets you add all sorts of interactivity that would be impractical if it were slower. For instance, my shell prompt shows whether the current directory is managed by Git, and if so, whether the status is clean. I would never tolerate my terminal being detectably slowed by such a thing. With git, it's not. There are a thousand little ways where having tooling be fast enough is make-or-break: if it's not, people don't use it. Git is fast enough for all the most common operations. Other options were not.

chx 2y ago

So in exchange for a little speed we are stuck with one of the most user hostile tools out there. That's not the deal I would have wanted to make. The interface is atrocious as some switches change completely what the command does -- this was partially acknowledged and fixed in git switch but there's so much more, it loses work way too easily and some of the concepts are near impossible to grok. (I did learn git eventually but that doesn't mean I like it. It's more of an uneasy truce than a friendship.)

kstrauser 2y ago
It wasn't a little speed. Other options were many times slower. I just renamed a large subdir in a large project. `time git status` took 41ms. That kind of speed lets you add all sorts of interactivity that would be impractical if it were slower. For instance, my shell prompt shows whether the current directory is managed by Git, and if so, whether the status is clean. I would never tolerate my terminal being detectably slowed by such a thing. With git, it's not. There are a thousand little ways where having tooling be fast enough is make-or-break: if it's not, people don't use it. Git is fast enough for all the most common operations. Other options were not.