Hallo allerseits,
Arne Babenhauserheide ſchrieb am 12.05.2010 16:03 Uhr:
Ich selbst habe mir inzwischen schon mehrfach mit git bei Standardaufgaben böse
in den Fuß geschossen (soweit, dass ich neu klonen musste), mit Mercurial
dagegen noch nie.
Dann kann ich allerdings gut nachvollziehen, warum Du jetzt Git eher
abgeneigt bist, so etwas sollte natürlich definitiv nicht passieren. Ich
selbst habe mir erst ein einziges Mal ein Git-Repository so total
vermurkst, dass ich mir lieber das letzte Backup neu geklont habe, aber
dass war definitiv mir anzulasten – ich war da noch hundertprozentig in
der alten SVN-Denke verhaftet und wusste mit einem DVCS noch nicht
richtig umzugehen.
Und Mercurial bedient sich grundlegend wie Subversion, wenn man im Kopf behält,
dass commit nur lokal wirkt und pull/push neue Änderungen holen bzw.
rausschicken.
Wie bereits gesagt bin ich der Ansicht, das sich Mercurial und Git in
der Bedienung nicht so sehr voneinander unterscheiden; und gewisse
Schwierigkeiten vom Umstieg von SVN auf ein DVCS sind (leider) einfach
nicht zu vermeiden, einfach da sich hier ganz neue Arbeitsabläufe
eröffnen. Aber auch Git kann man wie ein SVN bedienen … man kann sogar
auf ein SVN zugreifen :).
Doch: Das Mercurial Plugin funktioniert auch in die andere Richtung:
Klar, das Plugin selbst funktioniert bidirektional und kann die beiden
Formate ineinander unwandeln aber es liegt eben nur für hg- und nicht
für git-Clients vor (das meinte ich).
Mercurial baut auf jedem System auf dem auch git baut […] in Python[…]
geschrieben
<humor>Das wäre dann wieder ein Punkt für Git: “Python? That is for children. A
Klingon Warrior uses only machine code, keyed in on the front panel switches in raw
binary.” ;)</humor>
Für mich ist seltsamerweise gerade die Datenstruktur ein Grund Mercurial zu
nutzen.
Ich finde das doch recht witzig, wir finden den selben Aspekt wichtig,
aber sind zu genau entgegengesetzten Einschätzungen gekommen. An der
Git-Datenstruktur schätze ich, dass sie auf der untersten Ebene recht
simpel ist und gleichzeitig jede Redundanz vermeidet – vielleicht sind
deshalb die git-Repositories im Allgmeinen die Kleinsten (ja, ich habe
hier mal wieder ein git gc vorausgesetzt).
Es verwendet zwar auch Patches, speichert sie aber in einem Dateibaum, der
bessere Zugriffssemantiken bietet (Festplatten-seeks vermeiden) und nutzt
snapshots (wie in Videokomprimierung), um den Zugriff zu beschleunigen.
Eigentlich arbeitet Git da recht ähnlich, in den Packfiles gibt es auch
unkomprimierte Schnappschüsse, Deltakodierung und Indizierung für einen
schnelleren Zugriff. Ich glaube, in dieser Frage werden wir einfach
nicht zueinander finden … einigen wir uns darauf, das wir uns uneinig
sind :).
Arne Babenhauserheide ſchrieb am 18.05.2010 07:42 Uhr:
Christian Kluge ſchrieb:
1.7.* ist doch schon seit Ewigkeiten raus
Wird aber von den Gentoo-Maintainern noch nicht als stabil betrachtet, deshalb
habe ich es nicht. Ich nutze Testversionen nur bei den Sachen, bei
denen ich wirklich die neusten Features testen will. Der Rest hat einfach zu
laufen, und da vertraue ich auf das Urteil der Maintainer.
Und ich würde keinen Distributions-Maintainern glauben, die glauben
kompetenter als die eigentlicher Software-Maintainer zu sein ;): “The
latest stable Git release is v1.7.1.” (http://git-scm.com/).
git checkout -h
Ah, darauf warte ich seit Jahren!
Dann hat Dir die neue Version doch etwas gebracht,
#Friede_Freude_Eierkuche :).
Allerdings könnten „-b<new branch> → branch“ u.ä. doch etwas ausführlicher
sein…
“Specifications are for the weak and timid!”¹ ;) – aber inzwischen ist
die Git-Dokumentation recht gut ausgebaut (am Anfang war die wohl noch
/richtig/ mies im Vergleich zu Mercurial), wobei ich niemanden empfehlen
würde, Git oder auch Mercurial ausſchließlich über die Manpages zu
lernen. Dafür gibt es einfach viel zu viele, und man kann sich ja wohl
kaum alphabetisch durchlesen … besser ist es da, mit einem guten
Tutorial anzufangen.
Nebenbei: Hast du gemerkt, dass auf einem deutschen System der Großteil der
Ausgabe von Mercurial auf Deutsch ist?
Erst jetzt, wo Du es sagst :). Wobei ich kein Problem mit Englisch habe,
und bei Kommandozeilenbefehlen sogar lieber englischſprachige Manpages
lese, einfach weil ich mir dann die Abkürzungen besser merken kann – rm
-f steht ja für “remove --force”, und nicht für löschen --erzwingen.
Viele Grüße,
Dennis-ſ
¹ http://gradha.sdf-eu.org/textos/klingon_programmer.en.html
