With Git, nearly all operations are performed locally, giving it a huge speed advantage over centralized systems that constantly have to communicate with a remote server. In addition, Git uses delta encoding to only transmit the changed pieces of files across the network, saving time in large repos.
Git really suffers from the lack of abstraction made during its conception. Just as a proof, a generator of git-like man pages has been created to celebrate that weirdness.
That said, the documentation is getting better and better; even so, you must grasp the internals (=implementation details) to really make full use of git.
The popularity of Git has changed quite a bit over the past recent years, (leaving aside SubVersion as a competitor within the same type of tool as Git), it has become one of the most commonly known used tool for Distributed Version Control Systems for users of all kinds, including projects of all types. You'll have an easier time getting people already involved in open source to contribute than if they had to learn another SCM.
The large number of commands and functions that Git provides can be discouraging for beginners. Learning how Git works can be a difficult concept to grasp at first.
Git allows you the ability to edit your commit history. For example: if you're making a PR and you have a bunch of poorly organized commits, or lazy commit messages, or commits that aren't broken up properly then it's very useful.
Binary files (images, music... etc) are not handled so efficiently when there are many versions, since each version must be stored locally (which is unavoidable with distributed version management). nevertheless it is an issue.
However, there is a git extension available (git LFS) that addresses this issue.
Due to the Windows file system, e.g. a git gc (garbage collect) process sometimes cannot complete because Windows is locking files that are in use so that they cannot be deleted.
This often occurs when an IDE is monitoring a repository during such a process.
The ref log is one of the greatest (not commonly known) features of git. With it you can:
Undo almost every history changing operation (including git reset or git rebase or even undo an undo)
Compare results of an operation with the state before that operation
Revive accidentally lost branches
See per branch/ref what operations are executed upon them
Because of this you never have to worry whether a command destroys your (committed) data or history. You can always try freely and go back if it's not to your likings.
Though it definitely has improved in recent versions, Git on Windows is still slower than on Unix-based operating systems.
That said, almost everything is slower on Windows than the equivalent on a Unix based os. And also, it is still quick enough and (with most operations) quicker than other SCMs.
Gits storage model is quite simple. Once you understand it, git's sometimes hard to grasp CLI methods become clearer.
Once you know the power of the CLI, you can do anything with it.
This is also one of the reasons why data corruption is rare, easy to check and usually easy to fix.
In contrast to branches, tags don't track remote tags, so it is not possible to judge from the locally available data whether a tag exists in a remote repository or points to the same commit as a tag in the remote repository.
The CLI is the most powerful frontend of Git, due to it's subcommand-oriented design, it's reliable and gets you to know more about what's the purpose of each command.
Git doesn't handle binary files (bins, images, archives, etc.). Once someone starts tracking them, removing them completely from the history is a bit of a mess (filter-branch + all cloned repo's have to rebase, etc.).
Sharing code and projects in an open source world is a must and trying to working with multiple Source Code Control systems does not help the ecosystem.
Mercurial makes it pretty darn hard to delete history by mistake. In Git, if you mistakenly commit to HEAD and switch to a different branch, your commit is toast. Yes, you can dig through the reflog but most users don't even know of its existence and will wish they didn't once they find out.
"Subversion is the most pointless project ever started" -- Linus Torvalds
"if you like using cvs, you should be in some kind of mental institution or somewhere else. " -- Linus Torvalds
SQLite might be the most widely deployed software/library on the planet, with more testing code than feature code. Consequently, you can trust Fossil to be developed with similar vigor and attention to detail.
Fossil includes source code management, bug tracking, a wiki, and technotes.
It even includes its own web server, though it can fairly easily be incorporated into other webservers.
Fossil can be run as a CGI application behind apache, nginx, lighttpd or althttpd, in fact any httpd that supports CGI. But it does not require a webserver, it can run as one itself, serving just one, or multiple repositories.
Fossil is secure: by design, it never forgets anything. This pilosophy makes it very difficult to mess up a repository, or lose data, by making a false maneuver.
At the same time, Fossil does recognize that people do sometimes make mistakes. For example, it is possible to amend a commit message (much) later on. It is also possible to change a revision’s branch after the fact.
One fossil repository can have multiple checkout trees on the same machine, each for a different version. This can be used to support staging, and for quick fixes on older versions without disrupting the current development process. No need to duplicate the repo for that.
Fossil's bug tracker only works with the web interface or the command-line interface. There's no native GUI client supporting it.
There are some independent GUI clients out there, but none of them support Fossil's full range of abilities.
Svn is hard to use on multi-topics workflows. Branches exist but are often not used because of the fear of the merge hell.
Also, conflicts are a big deal and happen on the server; it feels like you only have one try and no way to abort/retry your conflict.
It has linear history, central repository and management. Lacks too complex features, almost every developer is familiar with it, so everyone knows what to expect and how to work with it.
Perforce has shown itself as very capable when it comes to managing binary files. That's why it's still the go to version control system in game development.
CVS is an ancient version control system that was a very useful tool back in the days, but a lot of progress has been made since then. Recommending CVS today would be like recommending typewriters instead of computers for writing.