But, ok: pull and fetch are really similar, but not really. Here’s a hammer, and another hammer that looks almost exactly the same except it works just a little differently, and if you use the wrong one situationally you can fuck up your history and have to spend an hour unfucking it.
You can change history. Not only can you, but it’s a common workflow, and it, too, easily leads to messed up clones. This was simply a really stupid design decision for a VCS.
The vast variety of errors you can encounter working with others - the one key feature of a DVCS - is astonishing. TF is “fast forward?” Don’t answer that, I know, but you know what no other DVCS suffers from? Fast forward restrictions. Or, how about detached heads? That’s a pretty uniquely git-level idiocy.
Merging is so badly implemented, it’s a common requirement for projects to demand that MRs be squashed down into a single commit.
Rebasing is even worse, such that users find themselves squashing history just to be able to successfully rebase.
git contributed no clever features, such as Darcs’ patch-based management; it provided no simplicity, like Mercurial; and, frankly, if it weren’t for github, it wouldn’t be nearly as popular as it is. Github was so innovative and useful, it overcame the handicap of being implemented on git. git eventually got a bisect command, so I can’t complain about that anymore.
I’m really pinning my hopes on jujutsu; so far, it makes working with git better enough that I don’t mind using it, although it’s still not quite as good as Mercurial, and it’s still very much a work in progress.
You know where git doesn’t suck? If you’re working on a project, alone, and you never branch. Then it’s not so bad. But, then, you may as well just keep your code in btrfs and make snapshots instead of commits.
Why? It’s clearly an opinion.
But, ok: pull and fetch are really similar, but not really. Here’s a hammer, and another hammer that looks almost exactly the same except it works just a little differently, and if you use the wrong one situationally you can fuck up your history and have to spend an hour unfucking it.
You can change history. Not only can you, but it’s a common workflow, and it, too, easily leads to messed up clones. This was simply a really stupid design decision for a VCS.
The vast variety of errors you can encounter working with others - the one key feature of a DVCS - is astonishing. TF is “fast forward?” Don’t answer that, I know, but you know what no other DVCS suffers from? Fast forward restrictions. Or, how about detached heads? That’s a pretty uniquely git-level idiocy.
Merging is so badly implemented, it’s a common requirement for projects to demand that MRs be squashed down into a single commit.
Rebasing is even worse, such that users find themselves squashing history just to be able to successfully rebase.
git contributed no clever features, such as Darcs’ patch-based management; it provided no simplicity, like Mercurial; and, frankly, if it weren’t for github, it wouldn’t be nearly as popular as it is. Github was so innovative and useful, it overcame the handicap of being implemented on git. git eventually got a bisect command, so I can’t complain about that anymore.
I’m really pinning my hopes on jujutsu; so far, it makes working with git better enough that I don’t mind using it, although it’s still not quite as good as Mercurial, and it’s still very much a work in progress.
You know where git doesn’t suck? If you’re working on a project, alone, and you never branch. Then it’s not so bad. But, then, you may as well just keep your code in btrfs and make snapshots instead of commits.