I know it's distributed, but even when it's not really (i.e. I know only I'm using the branch and I'm up to date), and I want to do something like delete a few files, rename a few others, and add new files in the same revision, it does things like deciding some deleted files have been renamed to a new file because their content is similar. Apparently the most reliable way is committing the deleted files in one revision, then committing the renamed files in another revision, then committing new files in a third revision. So much for Linus' nice clean commit history.
Even reverting one single file becomes an odyssey in itself which could take other files with it.
If really have to read git's source code to understand how it works then that's a failure. It should have a handful of understandable commands with predictable outcomes.
And as for git's supposed raison d'etre, didn't Linus just say GitHub merges were useless garbage anyway? What task does GitHub call to perform the merge?
Biting the hand that feeds IT
