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 einzelne patches zu speichern (mit Metadaten, welcher wohin gehört) und dann und wann zu packen. Es zeigt die gleiche Sorgfalt und Klarheit, die ich auch sonst in Mercurial sehe (und die Git meinem Eindruck nach fehlt). Liebe Grüße, Arne
