Man muss sich bei git schon anstrengen etwas kaputt zu machen.
Das geht sogar sehr einfach:
Vergiss vor dem Pull, dass noch lokale Änderungen da waren, dann bekommst du ggf. einen Konflikt. Wenn du den löst, zeigt dir TortoiseGit einen "Special Commit" an. Wenn du dann denkst, dass du doch die Änderungen gar nicht gemacht hast und welche rausnimmst, machst du leider die vorhergehenden Änderungen kaputt.
Klar, wenn man weiß, was man tut, passiert so etwas nicht, aber ich habe das schon erlebt (einige Wochen nach der Einführung von Git) und habe das dann im Repository korrigiert (es war auch niemand sonst da, der das hätte machen können).
Die Arbeitsanweisung, die ich mir dann überlegt habe, lautete, dass jeder zuerst das Staging nutzt, um lokale Änderungen wegzunehmen, dann pullt und dann die lokalen Änderungen wieder zurück holt. Dann gibt es ggf. auch Konflikte, aber die entstehen dann nur lokal und beim Committen sieht man wirklich nur die eigenen Änderungen, so dass das alles unproblematisch ist.
Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen.
Ja, das ist es. Ich persönlich mag Git lieber, aber ich weiß auch, dass es nicht narrensicher ist und man schon aufpassen muss, ob man das tut, was man meinte.