4 ms·

Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I c

Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. Git is a tool, and it's certainly not going to be a 'flip a switch and everything is better'. It does require that you define how you're going to use it in your particular context, but the only tradeoff I can see with git is learning it. It's interface and naming is an absolute horror show of usability, but its no worse that something like regular expressions or vim/emacs. But once it's in place, you have change management calculus, and everything else was algebra at best. I understand the frustration of people who are used to having the benefits of open history in addition to open source. And who don't want to step back 10 years and learn dead end technologies, and who aren't used to being confronted with ivory towerism or gatekeeperism. Otoh, I also understand why a maintainer would want to keep their codebases close to their chest, when they've achieved expert level finesse in a project/codebase, and the noob hordes with their ill-conceived ideas demand responses to their pull requests because they spent their free time writing some crap, and demand you spend your free time educating them on why their patch is a tub full of fail.

lsh123 12y ago
I've replied to another comment - there are scenarios when Git is not the best choice (imho) :) Said that I am using Git for pretty much everything right now simply because it is "good enough" and I am lazy to switch between tools.
papaf 12y ago
I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. I don't want to get into an emacs/vi style flamewar but other VCSs have their own advantages, and are better in some situations: - I prefer SVNs handling of trees/subtrees. I can checkout and work on one small part of a large project. - Fossil has ticketing and wiki out of the box. It is easier to set up a server and enables true distributed offline working. - Mercurial is easier to use for the most frequent use cases.
- mixologic 12y ago
  Git's submodules and git-subtree are definitely clumsy to work with, but you can always use sparse checkout if you want to work on a small part of a large project. Ticket handling/wiki aren't really version control features. Decoupling those features from your VCS allows you to select the one that works best for your situation. Mercurial is easier to learn for the most frequent use cases, and its interface make a lot more sense. No argument there. But like I said earlier, once you do learn it, its no more difficult to use, follows the same paradigms, but really allows for the edge cases to shine.

lsh123 12y ago

I've replied to another comment - there are scenarios when Git is not the best choice (imho) :) Said that I am using Git for pretty much everything right now simply because it is "good enough" and I am lazy to switch between tools.

papaf 12y ago

I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. I don't want to get into an emacs/vi style flamewar but other VCSs have their own advantages, and are better in some situations: - I prefer SVNs handling of trees/subtrees. I can checkout and work on one small part of a large project. - Fossil has ticketing and wiki out of the box. It is easier to set up a server and enables true distributed offline working. - Mercurial is easier to use for the most frequent use cases.

mixologic 12y ago
Git's submodules and git-subtree are definitely clumsy to work with, but you can always use sparse checkout if you want to work on a small part of a large project. Ticket handling/wiki aren't really version control features. Decoupling those features from your VCS allows you to select the one that works best for your situation. Mercurial is easier to learn for the most frequent use cases, and its interface make a lot more sense. No argument there. But like I said earlier, once you do learn it, its no more difficult to use, follows the same paradigms, but really allows for the edge cases to shine.