Nincs szerintem egzakt definíció, én azt mondanám, hogy egy verziókezelőnek kell legyen ACID szerű működése, de a Git esetén nincs ilyen... ez ugyanúgy ad egy csomó dologban előnyt, mint a NoSQL az RDBMS-hez képest, de ad egy csomó hátrányt, amikor inkább RDBMS kellene NoSQL helyett, de erőltetve van a NoSQL, csak azért, mert az cool és fancy.
Mondjuk ilyen lehet egy adott időpontra visszaállni és abban mondjuk hibát keresni, mert valahol az a release fut. És Git esetén előfordul, hogy valaki beletett egy módosítást a local repójába, ott kicsit pihentette, készült egy build egy másik repóból, kiment mondjuk fejlesztői környezetbe, majd ezek után emberünk csinált egy remote push-t vagy pull-t és ha hibát keresnél, akkor azt látod, hogy valami nem stimmel. Oké, distributed rendszer, ilyen... de nem lehet az egész repót mindig tag-elni.
Láttam már olyat is, hogy a local commit dátummal játszott a fejlesztő, mert valami elbaszott és próbálta takarítani a nyomokat... jelentős bizalom kell a push engedélyezéséhez. Ha meg ez nincs meg, akkor a pull jelentős adminisztrációs teher tud lenni.
Nem véletlen az a sok szűkített frontend és workflow, ami Git elé tehető, hogy az ember ne csináljon véletlenül hülyeséget... sajnos a fejlesztők nagyon-nagy része nem Linux kernelfejlesztő, annak megfelelő fegyelemmel, hanem eléggé balfasz tud lenni.