Re: [Neo] Git und Mercurial
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 humorDas 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 „-bnew 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
Re: [Neo] Git und Mercurial
Dennis Heidsiek wrote: 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. Der einzige wirkliche Fehler den ich bisher (selbst bei einem Computer-DAU) mit Mercurial erlebt habe, ist zu vergessen zu pushen oder zu pullen (solange keine als experimentell ausgezeichnete Module genutzt wurden). Selbst einen merge habe ich letztens über’s telefon erklaärt, und das komplizierteste war, dass ich kein TortoiseHG nutze, der andere aber schon (finden der richtigen Tasten :) ). (auf der Kommandozeile wäre es noch einfacher gewesen) Aber auch Git kann man wie ein SVN bedienen … man kann sogar auf ein SVN zugreifen :). Wie mit hgsubversion (Mercurial extension die ähnliche Strukturen nutzt wie hg-git) :) 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). Jupp, aber es ändert nichts wesentliches am workflow (man muss halt einen Mercurial aufrufenden hook in seinem lokalen git repo erstellen :) ). Mercurial baut auf jedem System auf dem auch git baut […] in Python[…] geschrieben humorDas 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 ;) 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). Was ich im Gegenzug bei Mercurial schätze ist, dass die Struktur genau für ihre Aufgabe optimiert ist. Sie ist sogar auf Zugriffsstruktur von Dateisystemen optimiert: Daten sind im store in einem Dateibaum, der dem Arbeitsverzeichnis entspricht, weil sich so beim sortierten Auslesen (das machen die meisten Dateisysteme) der Festplattenkopf am wenigsten bewegen muss. Deswegen ist auch bei einem update via Mercurial die Platte sehr viel leiser als bei git (ich höre das deutlich; meine Platte rattert). Und deswegen sind git repos kleiner. hey, und ich kann gerade den Zirkelschluss zu Tastaturbelegungen ziehen: Ein Layout, das nur auf Tastenpositionen und Fingerwiederholungen achtet, hat (bei maximaler Optimierung) gezwungenermaßen bessere Tastenpositionen und weniger Fingerwiederholungen als eins, das zusätzlich beachtet, dass nicht erst ein Finger oben und dann der direkt daneben unten eingesetzt wird. Welches von ihnen besser zum Tippen ist, hängt von der Flexibilität der Finger ab :) Eigentlich arbeitet Git da recht ähnlich, in den Packfiles gibt es auch unkomprimierte Schnappschüsse, Deltakodierung und Indizierung für einen schnelleren Zugriff. Der Unterschied ist halt, dass das bei Mercurial direkt beim committen on- the-fly passiert. Aber sie haben auch beide immer wieder voneinander gelernt – was ich sehr gut finde! Ich glaube, in dieser Frage werden wir einfach nicht zueinander finden … einigen wir uns darauf, das wir uns uneinig sind :). Ich denke, da werden wir nicht drum rum kommen. Immerhin sind wir aber bereits fast an der untersten Ebene (statt „A B ⇒|⇐ B A“ sind wir bei „A macht das so, was ich wegen X besser finde als das, wie B es macht ⇒|⇐ Mir ist aber Y wichtiger als X, und das kann B besser“), so dass die Diskussion, finde ich, fruchtbar und sinnvoll war – und auch einen schönen Abschluss hat. 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/). Ich schon. Die distributions-maintainer sehen nämlich ein viel breiteres Bild als die Software-Entwickler. Sie testen gegen die verschiedensten setups und binden oft noch patches ein, um alles zum Laufen zu kriegen. Dann hat Dir die neue Version doch etwas gebracht, #Friede_Freude_Eierkuche :). Sie wird mir was bringen, wenn sie stable wird :) (am Anfang war die wohl noch /richtig/ mies im Vergleich zu Mercurial), Auch ohne den Vergleich, ja :) 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. Stimmt. Warum haben wir eigentlich kein `tut git` und `tut hg` als Erweiterung zu `man git` und `man hg`? Ein standard tutorial-viewer wäre toll!
Re: [Neo] Git und Mercurial
Dennis Heidsiek wrote: 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/). $ ls /usr/portage/dev-vcs/git/files/*patch /usr/portage/dev-vcs/git/files/git-1.6.6-always-install-js.patch /usr/portage/dev-vcs/git/files/git-1.7.1-always-install-js.patch /usr/portage/dev-vcs/git/files/git-1.7.0-always-install-js.patch $ cat /usr/portage/dev-vcs/git/files/git-1.7.1-*.patch | head -n 4 JS install cleanup fixes - Also ensure the minified JS is built before instaweb as it is referenced in the sed expression. Liebe Grüße, Arne
Re: [Neo] Git und Mercurial
Christian Kluge wrote: $ git version git version 1.6.4.4 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. git --version git version 1.7.1.28.g54c98 git checkout -h usage: git checkout [options] branch or: git checkout [options] [branch] -- file... -q, --quiet be quiet -b new branch branch -llog for new branch -t, --track track -2, --oursstage -3, --theirs stage -f, --force force -m, --merge merge --conflict styleconflict style (merge or diff3) -p, --patch select hunks interactively Ah, darauf warte ich seit Jahren! Allerdings könnten „-b new branch → branch“ u.ä. doch etwas ausführlicher sein… Nebenbei: Hast du gemerkt, dass auf einem deutschen System der Großteil der Ausgabe von Mercurial auf Deutsch ist? Liebe Grüße, Arne
Re: [Neo] Git und Mercurial (was: Re: Individualisierte Layouts als Vision?)
Dennis Heidsiek wrote: Stimmt, aus der (zeitlichen) Distanz wirkt das teilweise doch etwas übertrieben, aber die waren halt mit Herzblut bei der Sache … und jede Zeit hat ja sowieso ihre eignen Glaubenskriege, ich nenne jetzt einfach mal hg vs. git ;). Oh ja ;) (deutlich leichter für SVN Nutzer zu verwenden¹), Würde ich nicht mehr sagen, die beiden sind sich auch in der Bedienung doch sehr ähnlich – siehe Vortrag. 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. 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. Ansonsten verweise ich auf: http://www.whygitisbetterthanx.com/ Als Gegenpunkt zur besseren Lernbarkeit: ### Git ### $ git version git version 1.6.4.4 $ git checkout -h fatal: Not a git repository (or any of the parent directories): .git (Warum keine Hilfe?) $ git checkout --help …(man page)… NAME git-checkout - Checkout a branch or paths to the working tree SYNOPSIS git checkout [-q] [-f] [-m] [branch] git checkout [-q] [-f] [-m] [-b new_branch] [start_point] git checkout [-f|--ours|--theirs|-m|--conflict=style] [tree- ish] [--] paths... … When paths are not given, this command switches branches… If -b is given, a new branch is created and checked out, as if git-branch(1) were called… When paths are given, this command does not switch branches…In this case, the -b and --track options are meaningless and giving either of them results in an error… … $ git pull -h Usage: git pull [-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s strategy]... [fetch-options] repo head... Fetch one or more remote refs and merge it/them into the current HEAD. ### Mercurial ### $ hg version Mercurial Distributed SCM (version 1.5.2) Copyright (C) 2005-2010 Matt Mackall m...@selenic.com und andere Dies ist freie Software; siehe Quellen für Kopierbestimmungen. Es besteht KEINE Gewährleistung für das Programm, nicht einmal der Marktreife oder der Verwendbarkeit für einen bestimmten Zweck. $ hg update -h hg update [-c] [-C] [-d DATUM] [[-r] REV] Aliase: up, checkout, co Aktualisiert das Arbeitsverzeichnis Hebt das Arbeitsverzeichnis auf die angegebene Revision an. Wird keine Revision angegeben, wird zum Kopf des derzeitigen Zweigs aktualisiert, falls dieser ein Nachfahr des direkten Vorgängers der Arbeitskopie ist. Ansonsten bricht die Operation ab. … Optionen: -C --clean Entferne nicht versionierte Änderungen (kein Backup) … $ hg pull -h hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [QUELLE] Holt Änderungen aus dem angegebenen Projektarchiv Überträgt Änderungen aus einem entfernten Archiv in das lokale. Dabei werden alle Änderungen vom Archiv am angegebenen Pfad oder URL gesucht und dem lokalen Archiv hinzugefügt. Standardmäßig wird die Kopie des Projektes im Arbeitsverzeichnis nicht aktualisiert. … Wie schon auf Identi.ca gesagt, haben die GitHuber ein Plugin geschrieben, mit der ein Hg-Client mit einem Git-Repository arbeiten kann, schon von daher würde ich bei Neo eher zu einem Git-Repo tendieren, dann kann jeder den Client benutzen, der ihm am besten passt :). Leider haben die Bitbucker noch kein Hg-Plugin für Git geschrieben … Doch: Das Mercurial Plugin funktioniert auch in die andere Richtung: Du kannst einfach mit Mercurial clonen, in dem hg repo ein Git repo erzeugen (hg gexport) und dann mit git von da ziehen. → Details: http://mercurial.selenic.com/wiki/HgGit Es funktioniert also in jede Richtung – und Mercurial baut auf jedem System auf dem auch git baut (Mercurial ist in Python[¹] geschrieben, so dass es überall läuft wo es Python gibt – also fast überall). ¹: plus ein paar kleine, portable C Erweiterungen Ist doch schön, dann steckst Du doch in der Materie :). Und ich verhehle auch nicht, dass meine Sympatien eher bei Git liegen (obwohl ich am Anfang auch eher zu Mercurial tendierte, da es da einen schöneren und einfacheren Windows-Installer hatte … aber inzwischen finde ich die Git-Datenstruktur doch ziemlich elegant :)). Für mich ist seltsamerweise gerade die Datenstruktur ein Grund Mercurial zu nutzen. 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. → http://hgbook.red-bean.com/read/behind-the-scenes.html Das ist optimiert für das, was ich damit machen will, also Versionsverwaltung. Und das gleiche gilt für das UI von Mercurial, seine Hilfe usw. Konzeptuell passiert dasselbe, aber das Datenformat von Mercurial ist meinem Meinung nach einfach eleganter als
Re: [Neo] Git und Mercurial
Arne Babenhauserheide schrieb am 12.05.2010 16:03: Als Gegenpunkt zur besseren Lernbarkeit: ### Git ### $ git version git version 1.6.4.4 1.7.* ist doch schon seit Ewigkeiten raus $ git checkout -h fatal: Not a git repository (or any of the parent directories): .git (Warum keine Hilfe?) Siehe oben, weil die Version zu alt ist: git --version git version 1.7.1.28.g54c98 git checkout -h usage: git checkout [options] branch or: git checkout [options] [branch] -- file... -q, --quiet be quiet -b new branch branch -llog for new branch -t, --track track -2, --oursstage -3, --theirs stage -f, --force force -m, --merge merge --conflict styleconflict style (merge or diff3) -p, --patch select hunks interactively Mit freundlichen Grüßen Frakturfreak -- Wenns halt war, wies halt war, irgendwie wars, denn noch nie wars, dass es nicht irgendwie war. Mein Blog: http://frakturfreaks-kleine-dinge.1on.de/ signature.asc Description: OpenPGP digital signature
