4 ms·

While I agree with those safeguards, the big disadvantage (particularly when working with a large group of people) is that they are all defeatable by a stupid /

While I agree with those safeguards, the big disadvantage (particularly when working with a large group of people) is that they are all defeatable by a stupid / uninformed team member, particularly if it isn't noticed for a couple of months. Of course you can argue that we shouldn't work with stupid / uninformed people, but often it is unavoidable.

uxp 14y ago
That's the beauty of a distributed VCS. If my team member deletes every commit inside his master and tries to force push that to GitHub, either by accident or by malice, I have the true history for my master sitting on my local machine. I can then revoke his push access to our upstream, re-push the true master history I have a copy of, and then write him up for being stupid and/or uninformed. It doesn't matter if he was able to do that in HG or Git. If no one notices that such a thing happened for a couple of months, then we need to use better code review practices. Git won't prevent humans from making mistakes. Git will, however, complain if I try to push my master to the upstream's master and the histories don't match (if someone else deleted a previously merged commit), which can at least tip me off to something fishy. Then, I can either force push, and then tell all my other co-workers that the history has changed, or I can revert the destructive commit and carry on.