> CVE-2019-1351: While the only permitted drive letters for physical drives on Windows are letters of the US-English alphabet, this restriction does not apply to virtual drives assigned via subst <letter>: <path>.
These are strange - subst can create them in some cases (e.g. É:\ or 5:\) but they don't show up in subst's list output, nor in This PC, and Explorer can't browse them. But cd/dir works from a Command Prompt.
CVE-2019-1353:
When running Git in the Windows Subsystem for Linux (also known as
"WSL") while accessing a working directory on a regular Windows
drive, none of the NTFS protections were active.
I don’t understand that one. Doesn’t that imply a security bug in Windows?
It was easier to learn, shell integration with Windows existed (TortiseHg), help files were more gentle to newbies. Ultimately, I realize that Git "won" more because of Github than any specifically outstanding merits that Git itself had; if BitBucket had delivered what GitHub did in Hg before GitHub, I think we would all be Hg users right now.
Most of the horror stories with git are when people try to do crazy rebases. If you minimize the number of rebases, it is fine. (And in case you need to make some crazy rebase, remember to use tags to keep alive the old version in case it is necessary to undo all the mess.)
git reflog can be used to restore the last good commit before a rebase gone wrong. It's more of a pain to use that just resetting to a tag, but, it's a great safety net.
Bitbucket and GitHub had feature parity for much of the early years. The performance arguments (though some of them were rather spurious) and the network effects of the Linux team itself seem more critical for git winning than GitHub. (As a devout darcs user at the time, I watched from the bleachers of that fight.)
These are strange - subst can create them in some cases (e.g. É:\ or 5:\) but they don't show up in subst's list output, nor in This PC, and Explorer can't browse them. But cd/dir works from a Command Prompt.