o Complex, confusing terminology including multiple non-obvious names for various components. o Huge number, about 148, of commands with many sub-commands that

o Complex, confusing terminology including multiple non-obvious names for various components. o Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things. > Git has a learning curve. No way around it. I would argue that it is an extremely powerful vcs worth spending the time to learn. o git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. > There are some situations where rebase are permissible. Again, this goes back to the learning curve. On most teams, though, I find it helpful to just put a ban on rebasing. o Git has been bundled with code review systems like Gerrit which encourages developers to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, debug, engage in trial and error, or all the other things developers actually do. When a bug does slip through as if often does despite the supposed quality-control benefits of code review, then reconstructing what happened from the rebased "history" can be a nightmare. > I've never heard of this/this happening but this doesn't sound like a specific gripe against Git. Either way I don't know enough to counter it. o There are numerous commands to do similar, overlapping but nonetheless different tasks. If for example you want to back up to earlier versions of code you can do git revert, git reset --hard, git reset --soft, git checkout -- <SHA>, git checkout <SHA> -- all of which do different but overlapping things. > These commands do similar, but different things. Part of the allure of Git is its immense flexibility and power. On the CLI, the only way to do this really is to have a lot of commands and options. Again, take the time to learn Git and you will be rewarded. o A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches, making locating changes and reconstructing the history of changes extremely difficult. A change can occur on a local branch on one developer's computer, be rebased into another local branch and then finally rebased or merged into the shared "master" branch. > This is a workflow problem. You need to talk to your teammates and establish habits to stay in sync. o Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files as well as snapshots of the entire project. Even if you track down the tricks to compile the SHA into a program or file name, the SHA is not sequential making it difficult to know which version of a file or group of files is in a program. > I've never found this to be an issue whatsoever. o These many flaws in git and its command line interface have resulted in a proliferation of third-party add-on tools like the Android project's repo utility, gitk, magit in Emacs, sourcetree, many of which fail to fully wrap the complexity of Git forcing users to both master the wrapper tool and the Git command line especially on more complex projects. Some of these GUI/wrapper tools like Android repo seem to have serious bugs as well. > The CLI is fine and consistent IMO. Sourcetree is great if you prefer GUI and has all the power most users need. o Lack of backward compatibility with RCS-style version control systems like Subversion. Instead of building on 30+ years of success and experience with RCS-style version control systems, but extending them sensibly for distributed projects, Git took a "reinvent the wheel badly" approach. > That is a ridiculous thing to say. Git brings a very unique and powerful paradigm to VCS which is the distributed model. It also allows for a variety of different workflows and usages due to its flexibility. Not adhering to an existing standard is not ipso facto a flaw. o A fanatical, cult-like following apparently mesmerized by Linus Torvalds that is unable to recognize or acknowledge the many obvious problems with Git. > I have extensively used CVS, SVN, Git, and Mercurial and I vastly prefer Git over the others. SVN is fine, but Git allows for a special flexibility that once you become a power user makes it hard to go back to anything else. I don't think there is anything cult-like surrounding Git... it is simply very popular, and rightfully so.