Git - SourceTree - alten Quelltext auschecken

[Stevie]

Zitat:

Zitat von Sherlock (Beitrag 1457362)

Also wenn git es tatsächlich erlaubt, mit simplen Befehlen das Repository derart zu zerstören, daß Commits auch auf dem Server entfernt werden können, dann bin ich froh bei Mercurial geblieben zu sein. Wollte zwar wegen meinem lokalen BitBucket auf Git umsteigen, aber mit hg-git komme ich dann weiterhin bestens zurecht.

Bei der Entscheidungsfindung hg oder git kam mir immer wieder mal das Grausen, was die git-Entwickler so für notwendig hielten...

Und was ist eigentlich dieses "auschecken"? Hg und git brauchen sowas doch gar nicht. Man Updatet auf einen Stand und wenn man fertig ist, wird gemerged und commite, oder meinetwegen ein Pull-Request geschickt.

Oh bitte hör auf, solchen Unsinn zu glauben oder weiter zu verbreiten. Es ist mit enormen Hürden verbunden, Commits auf dem Server zu überschreiben. Erstens sind die lokal immer noch vorhanden und werden nicht einfach vom nächsten git gc gelöscht und außerdem muss man für eine deratige Aktion bewusst einen force push machen - und je nach git Verwaltung kann man das verbieten.

Da ist es einfacher eine Datei mit Shift+Delete zu vernichten, so dass du irgendwelche Disk Tools bemühen musst, um sie wieder herzustellen.
git checkout ist nix anderes als auf einen bestimmten Branch zu wechseln - ich bin sicher, das kann man in Mercurial auch.

[Sherlock]

Ich hab doch nicht damit angefangen. Ich hatte meinen Einstieg in diesen Thread eingeleitet mit "es kann nichts kaputt gehen". Freilich unterstelle ich mal, die Abwesenheit von Mutwilligkeit. Dann kamen entsetzte "Doch man bekommt alles ganz einfach kaputt" Einwände.

OK, ich wußte nicht, daß "hg update" von git checkout genannt wird. Halte ich persönlich für kontraproduktiv, weil man einen SVN-Begriff zweckentfremdet, aber mir egal.

Ich halt mich jetzt lieber raus. Bin ohnehin nur indirekter git Anwender.

Sherlock

[freimatz]

Zitat:

Zitat von Stevie (Beitrag 1457351)

Zitat:

Zitat von freimatz (Beitrag 1457291)

Zuerst nur optisch, wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log sind sie nach dem nächsten pack (git gc) wirklich weg.

Auch wenn ich zustimme, nen Branch oder nen Tag vom aktuellen Stand anzulegen, stimmt das nicht.
Das ref log hat eine Verfallsdauer von 90 Tagen als Default. Da haut auch nen standard git gc nix weg von.

Ich stimme dir in allem zu, ausser in "stimmt das nicht". Ich schrieb ja "wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log" (da fehte dann von mir ein Komma).

Das mit dem "und sogar auf den Server gepusht" von Sherlock habe ich übersehen. Sorry. Dann kann man nur lokal was kaputt machen und im schlimmsten Fall wieder auf einen master Stand. Ausnahme dann wie Stevie schrieb dann mit Böswilligkeit (oder absichtlicher Gutwilligkeit). Hm, wenn ich so überlege habe ich das selber schon öfters gemacht: auf einem Branch; etliche commits; gepushed; reset auf einem älteren Stand; (push geht dann nicht); branch remote gelöscht, neuer push. (In disen Fällen war der branch nur von mir genutzt)

Die Entscheidungsfindung hg oder git hatten wir auch mal und ich bin froh im nachhinein, dass wir zu git gewechselt haben.

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1457410)

Ich stimme dir in allem zu, ausser in "stimmt das nicht". Ich schrieb ja "wenn sie nirgendwo mehr gebraucht werden, also auch nicht im sogenannten ref log" (da fehte dann von mir ein Komma).

Wenn sie nicht mal mehr im reflog sind, dann sind 30 Tage vergangen, denn das ist die Standardeinstellung für wie lange unerreichbare Einträge dort vorgehalten werden (gc.reflogExpireUnreachable). Ansonsten muss man schon nen git reflog expire für aufrufen.

Zitat:

Zitat von freimatz (Beitrag 1457410)

Die Entscheidungsfindung hg oder git hatten wir auch mal und ich bin froh im nachhinein, dass wir zu git gewechselt haben.

Dito und ich war seinerzeit sogar für hg :wall: