" ugy hogy az a historybol is teljesen eltunjon."
Nem írtam azt, hogy a history-ból is eltűnik. cvs remove, svn delete
Git esetén se tűnt el a history-ból, pláne nem minden history-ból. Ezért is tudták visszaállítani.
Itt most két dolog keveredik:
1. A feltett módosításod felülírják. Ezt lehet sokféleképpen, akár egy sima commit-tal is, rossz merge-dzsel, ...
Én jól csináltam mindent, de valaki más belebarmolt. History(k) lapján (ha észrevesszük) visszaállítható a dolog.
2. History megváltoztatása. Erre valóban nem nyújt támogatást az SVN és CVS, de Git esetén sem az összes history változik. "A" felhasználó felrakja az Fe85... commitot, "B" felhasználó meg átírja D76f... commit-ra. "A" felhasználó history-jában ott van az általa felrakott commit, ami nem ugyanaz, mint amivel felülírta "B" felhasználó. Ha "A" felhasználó rakott fel hibásan valamit, akkor ez egy jó dolog, hogy "B" ki tudta javítani jóra. Ha "B" tudatlanságból használt egy olyan funkciót, amit nem tud, hogyan működik, akkor ez rossz eredményt ad.
A késes példa (példa az eszköz rossz használatára) nem tetszett mindenkinek, ezért álljon itt a shell rm parancsa. Eleve az rm (kés) nem biztonságos, mert törölni tud egy nem hozzáértő egy fájlt, amit a legtöbb fájlrendszernél nem is tud visszaállítani, sokkal biztonságosabb az ls parancs (kanál). Ráadásul az rm nem is hajlandó védett állományt törölni (hasonlóan, mint a push a Git-nél), de ráerőszakolhatjuk a -f flag-gel (hasonlóan, mint a Git-nél). Van aki szerint ez rossz, sokkal jobb, ha nem is lenne rm parancs, de ha van, akkor se legyen -f flag-je. Ezzel viszont azt a képességet vesztjük el, hogy rengeteg nekünk nem kellő védett fájlt nem tudunk hatékonyan törölni.
Mindenki eldönti mit tart biztonságosnak, hatékonynak és aszerint választ eszközt magának.