Warum ist Mercurial einfacher als Git?

204

Wenn ich Vergleiche betrachte, scheint es mir, dass es eine 1: 1-Zuordnung zwischen ihren Funktionssätzen geben könnte. Eine häufig zitierte Aussage ist jedoch, dass "Mercurial einfacher ist". Worauf beruht diese Aussage? (wenn überhaupt)

Tamás Szelei
quelle
21
Komisch, ich habe nie gehört, dass Mercurial einfacher ist. Ich habe mehr Dokumentation für Git gefunden (möglicherweise Wahrnehmung), also habe ich das gelernt.
Nic
16
Weil es von Linus gemacht wurde?
Job
124
Ich habe mich hier in das Gebiet des Heiligen Krieges begeben, aber ich fand Mercurial einfacher zu bedienen als Git, weil ich mich als Windows-Benutzer von Mercurial begrüßt und von Git wie ein Freak und ein Verlierer behandelt fühlte. Ich weiß, dass ich anthropomorphisierende Software bin, und ich weiß, dass beide problemlos unter Windows verwendet werden können, aber das ist der Eindruck, den sie beide vermitteln.
Carson63000
24
hginit.com
Svish
11
Ich frage mich, wie viele Leute Git verwenden würden, wenn es Github nicht gäbe oder nicht so viele hochkarätige Projekte?
Chris S

Antworten:

240

Beispiel: Nehmen wir an, Sie möchten den Benutzernamen für alle vorherigen Commits ändern. Ich musste das aus verschiedenen Gründen mehrmals tun.

Git Version

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Mercurial Version:

authors.convert.list Datei:

<oldname>=<newname>

Befehlszeile:

hg convert --authors authors.convert.list SOURCE DEST

Nun, welches sieht einfacher zu bedienen aus?


Hinweis: Ich habe 2 Jahre ausschließlich mit Git gearbeitet. Das ist also kein "Ich hasse es, ich habe es nicht in 2 Sekunden bekommen" -Rant.

Für mich ist es die Benutzerfreundlichkeit. Git ist sehr linuxorientiert mit einer Linux-Art, Dinge zu tun. Das bedeutet Befehlszeile, Manpages und es selbst herauszufinden. Es hatte eine sehr schlechte GUI (Anmerkung: Ich habe das von msysGit vor ungefähr einem Jahr aus gemacht), das schien mir nur im Weg zu stehen. Ich konnte es kaum gebrauchen

Die Kommandozeile war schlimmer. Da es sich um ein Linux-orientiertes Programm handelt, war die Verwendung unter Windows sehr schwierig. Anstelle eines einheimischen Ports wurde git einfach mit MinGW (Think Cygwin) verpackt, was die Arbeit damit erheblich erschwerte. MinGW ist keine Windows-Eingabeaufforderung und verhält sich einfach anders. Es ist verrückt, dass dies der einzige Weg ist, mit Git zu arbeiten. Selbst unter Linux schien es die einzige Möglichkeit zu sein, mit einer geraden Befehlszeile zu arbeiten. Projekte wie RabbitVCS halfen einigen, waren aber nicht sehr leistungsfähig.

Der befehlszeilenorientierte Ansatz und die Tatsache, dass es sich um ein Linux-Programm handelt, bedeutete, dass fast alle Anleitungen, Hilfedokumentationen und Forum- / QA-Fragen darauf beruhten, monströse Befehle wie oben auszuführen. Die grundlegenden SCM-Befehle (Festschreiben, Ziehen, Drücken) sind nicht mehr so ​​komplex, und die Komplexität nimmt exponentiell zu.

Ich hasse auch den einen Ort, an dem viele OSS-Git-Benutzer rumhängen: Github. Wenn Sie zum ersten Mal zu einer Github-Seite gehen, werden Sie mit allem belästigt, was Sie tun können. Für mich sieht eine Projekt-Git-Seite chaotisch, beängstigend und übermächtig aus. Sogar die Erklärung, was das Projekt ist, wird nach unten gedrückt. Github schmerzt Leute, die noch keine vollständige Website eingerichtet haben. Der Issue Tracker ist auch schrecklich und verwirrend. Funktionsüberladung.

Git-User schienen auch sehr kultig zu sein. Git-Benutzer scheinen immer diejenigen zu sein, die "Heilige Kriege" beginnen, über die DVCS besser ist, was Mercurial-Benutzer dann zwingt, sich selbst zu verteidigen. Websites wie http://whygitisbetterthanx.com/ zeigen Arroganz und eine fast "Use my software or die" -Mentalität. Oft habe ich verschiedene Orte der Hilfe aufgesucht, nur um nicht X zu kennen, um X vorher zu benutzen, um Windows zu benutzen usw. Es ist verrückt.


Mercurial hingegen scheint eher auf die freundlichere Herangehensweise hinzuarbeiten. Ihre eigene Homepage scheint für neue Benutzer viel freundlicher zu sein als Gits . In einer einfachen Google-Suche ist das fünfte Ergebnis TortoiseHg, eine sehr schöne GUI für Mercurial. Ihr gesamter Ansatz scheint zunächst Einfachheit zu sein, später Macht.

Mit Mercurial habe ich keinen SSH-Quatsch (SSH ist die Hölle unter Windows), ich habe keine dumm komplexen Befehle, ich habe keinen Kultbenutzer, ich habe keine Verrücktheit. Mercurial funktioniert einfach.

TortoiseHg bietet eine tatsächlich benutzbare Oberfläche (obwohl sie in letzter Zeit offenbar wächst), die tatsächlich nützliche Funktionen bietet. Die Optionen beschränken sich auf das, was Sie benötigen, und beseitigen Unordnung und Optionen, die selten verwendet werden. Es bietet auch viele anständige Standardeinstellungen

Mercurial, der sehr freundlich zu Neuankömmlingen war, war sehr leicht zu erlernen. Sogar einige der komplexeren Themen wie das unterschiedliche Verzweigungsmodell und die Bearbeitung des Verlaufs waren sehr einfach zu verfolgen. Ich nahm Mercurial schnell und schmerzlos auf.

Mercurial funktioniert auch nur das erste Mal mit wenig Setup. Unter JEDEM Betriebssystem kann ich TortoiseHg einfach installieren und alle gewünschten Funktionen (hauptsächlich Kontextmenübefehle) nutzen, ohne nach verschiedenen Guis suchen zu müssen. Ebenfalls fehlt das Einrichten von SSH (die Hälfte der Anleitungen sagt, dass sie Putty, Plink und Pagent verwenden sollen, während die andere Hälfte sagt, dass sie ssh-keygen verwenden sollen). Für neue Benutzer benötigt TortoiseHg Minuten zum Einrichten, während Git 30 Minuten bis eine Stunde mit viel Googeln benötigt.

Zuletzt haben Sie die Online-Repos. Githubs-Äquivalent ist BitBucket, das einige der oben beschriebenen Probleme aufweist. Es gibt jedoch auch Google Code. Wenn ich zu einem Google Code-Projekt gehe, bekomme ich keine Funktionsüberladung, sondern eine schöne, saubere Oberfläche. Google Code ist eher eine Online-Repo- / Website-Kombination, die OSS-Projekten wirklich hilft, die noch keine Website eingerichtet haben. Ich würde Google Code sehr gerne für einige Zeit als Projektwebsite verwenden und nur dann eine Website erstellen, wenn dies unbedingt erforderlich ist. Der Issue Tracker ist ebenfalls leistungsstark und passt gut zwischen Githubs fast unbrauchbarem Issue Tracker und Bugzillas Monstrosität .

Mercurial funktioniert immer nur beim ersten Mal. Git kommt mir in die Quere und ärgert mich nur, je mehr ich es benutze.

TheLQ
quelle
6
Kommentatoren : Kommentare dienen der Klarstellung und nicht der ausführlichen Diskussion. Wenn Sie eine Lösung haben, hinterlassen Sie eine Antwort. Wenn Ihre Lösung bereits veröffentlicht wurde, stimmen Sie sie bitte ab. Wenn Sie diese Frage mit anderen diskutieren möchten, verwenden Sie bitte den Chat . Weitere Informationen finden Sie in den FAQ .
1
IntelliJ IDEA und Xcode 4 lassen sich wunderbar in Git auf ihren jeweiligen Plattformen integrieren, und für alltägliche Aufgaben müssen Sie nie die Befehlszeile verwenden.
4
Ich möchte hinzufügen, dass tortoiseGIT jetzt viel besser ist, wenn Sie GIT unter Windows verwenden möchten. Sie müssen sich immer noch mit den SSL-Schlüsseln auseinandersetzen und der Installationsprozess ist nicht reibungslos, aber wenn er abgeschlossen ist, funktioniert er problemlos.
Arkh
2
Git-Erweiterungen Ich persönlich finde es viel einfacher, unter Windows zu navigieren und damit zu arbeiten als TortoiseHG, und ich habe mit git bisher nur eine Befehlszeile verwendet.
KallDrexx
1
Ich bin irgendwie verblüfft über diese Zeile: "MinGW ist keine Windows-Eingabeaufforderung und verhält sich einfach anders. Es ist verrückt, dass dies die einzige Möglichkeit ist, mit Git zu arbeiten." Ich verwende die msysgit-Installation und Option 2, um von der Windows-Befehlszeile aus zu starten. Es funktioniert gut. Es gibt ein paar Dinge, die nicht funktionieren (wie das Caret, ein Zeilenfortsetzungszeichen in DOS), aber es gibt Alternativen zu denen (wie die Tilde), die gut funktionieren. Ich bin kein Kommandozeilen-Enthusiast (oder zumindest nicht, bevor ich anfing, Git zu lernen), aber die Verwendung von Git mit der Kommandozeile ist wirklich einfach. Vermisse ich etwas?
Kyralessa
80

Git gegen Mercurial

Mercurial gilt allgemein als einfacher und leichter zu lernen als Git. Im Gegenzug wird häufig die Auffassung vertreten, dass Git flexibler und leistungsfähiger ist. Dies ist zum Teil darauf zurückzuführen, dass Git tendenziell weniger umfangreiche Befehle bereitstellt, zum Teil aber auch, weil der Standard-Mercurial erweiterte Funktionen tendenziell verbirgt und es den Benutzern überlässt, die Mercurial-Konfigurationsdatei zu bearbeiten, um die von ihnen gewünschten erweiterten Funktionen zu aktivieren. Dies führt häufig zu der Annahme, dass erweiterte Funktionen in Mercurial nicht verfügbar sind.

Git Konzepte

Mercurial hat sich immer mehr auf Schnittstellenaspekte konzentriert, was das Lernen ursprünglich einfacher machte. Im Vergleich zu Git ist ein geringeres Verständnis erforderlich, um in nützlicher Weise mit Mercurial arbeiten zu können. Auf lange Sicht hat eine solche Einkapselung Mercurial das falsche Aussehen verliehen, weniger mächtig und eigenwillig zu sein, als es wirklich ist.

Zyklop
quelle
73
Mercurial verbirgt also nur die erweiterten Funktionen, während GIT alle Funktionen verbirgt ... ;-)
Ehrfurcht am
4
Git hat mehr Power. Zum Beispiel gibt es kein Äquivalent zu HEAD ~ 1 von git . Mercurial hat p (x), das sich über Zweige erstreckt, wie nutzlos. Es gibt keine Bühne in Hg. Alle Äste müssen gedrückt werden, wenn Sie drücken. Mercurial ist einfach nicht so flexibel, selbst mit allen Plugins wie histedit, shelf und rebase. Git Kommandozeile ist auch besser, es gibt dem Benutzer Hinweise, mercurials nicht. Ich bin gezwungen, dieses leicht verkrüppelte DVCS bei der Arbeit zu verwenden, und ich bin in Situationen geraten, in denen mercurial die Kraft fehlt, das zu tun, was ich will.
Keyo
22
@Keyo: Mercurial hat ~, siehe revsets . Es gibt keinen Staging-Bereich, aber Sie können ihn mit MQ emulieren, das so viel leistungsfähiger ist. Lernen Sie, das Tool zu verwenden, anstatt sich an das zu halten, was Sie von git kennen, es wird sich auszahlen.
Idan K
22
@Keyo: Sie müssen nicht alle Zweige mit Mercurial pushen, wenn Sie pushen. Sie können einen bestimmten Zweig ( hg push --branch BRANCH) oder bis zu einer bestimmten Revision ( hg push --rev REV) verschieben. Bitte beachten Sie hg help pushfür weitere Optionen.
Regent
1
Zu Ihrer Information, mit der Datensatzerweiterung kann man eine beträchtliche Teilmenge des Staging-Bereichs erhalten . OTOH, ich denke, die Regalerweiterung (nach dem Vorbild von "shelve" von Baazar und in der Nähe von "git stash") dient den meisten Zwecken der Nutzung des Bereitstellungsbereichs besser.
Brandizzi
47

Kontext: Ich benutze täglich sowohl Mercurial (für die Arbeit) als auch Git (für Nebenprojekte und Open Source). Ich verwende hauptsächlich textbasierte Tools mit beiden (nicht mit IDEs) und bin auf einem Mac.

Im Allgemeinen finde ich Mercurial einfacher zu bearbeiten. Einige Dinge, die ich finde, erleichtern Mercurial:

  1. Fehlender Index. Der Index ist ein leistungsfähiges Werkzeug, das viele Funktionen von Git ermöglicht, aber auch eine zusätzliche Ebene, die einen Schritt in viele Dinge einfügt, die ich regelmäßig mache. Mercurials Arbeitsablauf ähnelt eher dem von svn.
  2. Revisionsnummern statt shas. Dies ist eine kleine Sache, die mir die Arbeit mit alltäglichen Befehlen in Mercurial erheblich erleichtert. Es ist viel einfacher, ein paar Revisionsnummern während des Zurücksetzens, Zusammenführens usw. in den Kopf zu drücken, als dasselbe mit sogar verkürzten shas zu tun.
  3. Geäst. Gits Ansatz zur Benennung von Zweigen mit Commits ist leistungsfähig und unterscheidet sich wesentlich von anderen Versionskontrollsystemen. Es macht bestimmte Dinge viel einfacher. Ich finde, dass der Ansatz von Mercurial dem von Svn etwas besser entspricht und es einfacher macht, die Filialhistorie visuell zu verstehen. Dies kann nur eine Präferenz sein.
Alex Miller
quelle
6
+1 für die Erwähnung des Index; Ich denke , den Index und seine Wechselwirkungen sind die Sache , die als mercurial git schwieriger zu lernen macht.
Sean McMillan
18
Das hgÄquivalent zu gitZweigen wird tatsächlich aufgerufen bookmarks. Soweit ich weiß, haben hgFilialen keine Entsprechung in git.
Hank Gay
6
Ich bin in der gleichen Situation, mit mercurial bei der Arbeit und git zu Hause. Mercurial Branching nervt mich eher, ich habe gerne Privatfilialen und pushe sie, wenn ich will. Mercurial zwingt mich, Regale oder zusätzliche Repos zu benutzen. Revisionsnummern sind albern, gib mir den Hash. Die Bühne ist großartig in Sachen Git, das vermisse ich. Ich vermisse wirklich die Macht des Gits. Ich habe ein paar Dinge mit einigen Plugins gemacht, aber die Verzweigung nervt mich wirklich.
Keyo
6
@Keyo - Nach meiner Erfahrung ist die gitVerzweigung eine Teilmenge der hgVerzweigung. In können hgSie sowohl benannte als auch unbenannte (topologische) Zweige haben und sogar unbenannte Zweige wie gitLesezeichen verwalten. Ich habe den Punkt im Bereich der Inszenierung noch nie wirklich gesehen. Ich würde lieber unerwünschte Änderungen zurückstellen und dann sicherstellen, dass mein Code kompiliert und meine Tests abschließt, bevor ich ihn festschreibe. Ich kann mich dann aus dem Regal entfernen und weitermachen. Auch Charles Bailey "Massieren Hunks" (p90 +) macht mir Angst * 8' ): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
Mark Booth
7
@Keyo: In Mercurial werden private Zweige als "Lesezeichen" bezeichnet: Aktualisieren Sie auf die Stammversion hg bookmark keyo-stuff, führen Sie die gewünschten Schritte aus hg commit, und führen Sie sie schließlich aus hg push -B keyo-stuff. Wenn Sie Revisionsnummern nicht mögen, verwenden Sie sie nicht. Mercurial akzeptiert einen Hash überall dort, wo er eine Revisionsnummer akzeptiert, denke ich. Ich muss sagen, Ihre Kommentare, die Mercurial wegen mangelnder Funktionen verprügeln, haben sich in der Tat als ignorant und ein wenig aggressiv erwiesen. Sie tun nicht viel Gutes für das Klischee der Git-Benutzer!
Tom Anderson
29

Das ist sehr subjektiv und hängt von einer Person zur anderen ab, aber ja, ich würde das zu jemandem machen, der für VCS völlig neu ist, oder zu jemandem, der von einem "alten" VCS kommt, Mercurial wird einfacher erscheinen.

Zum Beispiel das Hinzufügen von Dateien, die Nichtexistenz des Index in Hg, die Leichtigkeit, zu einer alten Revision zurückzukehren und von dort aus zu verzweigen (einfach aktualisieren und festschreiben), als einige der "offensichtlichsten" Beispiele. Nun können die meisten Funktionen eines Systems in einem anderen emuliert werden und umgekehrt. Dies erfordert jedoch einige Kenntnisse in Git. In Mercurial sind die Standardeinstellungen (sofern ich sie so nennen darf) eher "benutzerfreundlich". Diese kleinen Dinge - der Wechsel hier und da, das nicht offensichtliche Verhalten in einem Befehl und so weiter ... diese Dinge summieren sich und am Ende scheint ein System einfacher zu bedienen zu sein als das andere.

Nur um die Antwort zu vervollständigen; Ich benutze Git, aber wenn ich ein VCS für jemanden empfehle, der "neu für sie" ist, empfehle ich fast immer Mercurial. Ich erinnere mich, als es zum ersten Mal in meine Hände kam, fühlte es sich sehr intuitiv an. Ich habe die Erfahrung gemacht, dass Mercurial weniger wtf / minute produziert als Git.

Turm
quelle
+1 für "weniger Gewicht / Minute" -1 für "das ist sehr subjektiv". Es ist nicht sehr subjektiv ... Ich weiß nicht, warum die Leute immer noch denken, dass Unterschiede in der Benutzeroberfläche subjektiv sind. Wenn ich die Befehle mercurial und md5 hash nehme, würden Sie nicht das Argument vorbringen, dass manche Leute einen md5 hash intuitiver finden als das Original, oder? (Ich hoffe nicht). Gleiches gilt für Git. Git ist nur dann einfacher als Mercurial, wenn Ihre Erfahrung mit Git wesentlich umfangreicher ist als die mit Mercurial.
weberc2
17

Ich denke, es ist so einfach: Mercurial hat eine vertrautere Syntax (insbesondere für SVN-Benutzer) und ist ziemlich gut dokumentiert. Sobald Sie sich an die Git-Syntax gewöhnt haben, werden Sie feststellen, dass sie genauso einfach zu bedienen ist wie alles andere.

pdr
quelle
7
Nee. Es gibt zu viele weitere Workflow-Schritte, als dass Sie dies als "andere Syntax" bezeichnen könnten. Sie müssen das zugrunde liegende Modell, das Sie bearbeiten, und den gesamten Status des Git-Index verstehen, um Git verwenden zu können. Zu sagen, SQL und Pascal seien zwei verschiedene Syntaxen für dasselbe, wäre gleichermaßen falsch. Git ist ein Dateisystem-Content-Versionierungssystem mit DVCS-Funktionen. Mercurial ist ein DVCS, das nicht alle Dateisystem-Content-Versionierungsoperationen durchführt, die GIT durchführt, sondern nur die Teilmenge, die alle DVCS-Benutzer benötigen.
Warren P
9

Die Wahrnehmung könnte sich im Laufe der Zeit ändern. Mercurial ist sehr gut designt, Git auch. Mercurial scheint leichter zu lernen zu sein (zumindest für mich), und es gab Schwierigkeiten, die ich in Git hatte, für die ich keine Parallele in Mercurial habe. Ich habe versucht, Python und Ruby zu lernen und bin mit Python schneller geworden. Das bedeutet nicht, dass Python immer und überall besser ist als Ruby oder dass es sogar besser für mich ist. Es ist genau das, was ich gelernt habe und bei dem ich festgehalten habe. Programmierer führen heilige Kriege oft aus persönlichen Gründen. Das machen auch andere Menschen.

Ich bin ein Mercurial-Benutzer, der versucht, Git gegenüber aufgeschlossen zu bleiben, und ich gebe frei zu, dass es nicht "meine neue Lieblingssache geworden ist", wie es Mercurial getan hat. Ich denke, Git ist wirklich sehr, sehr schön.

Ein Gegenbeispiel für GIT / Quecksilberkomplexität: In XCode ist auf dem Mac eine nette GIT-Unterstützung integriert. Mit Mercurial ist XCode weniger einfach zu verwenden als mit GIT.

Meine bisherige Erfahrung mit GIT hat gezeigt, dass ich verwirrt und verloren bin und die Dokumentation mehr lesen muss, während ich sie verwende. Ich glaube, dass eine Menge Dokumentation geschrieben wurde, aber nichts, was es mir ermöglicht hätte, es zu "groken". Zweitens kann ich Mercurial in Python leicht ändern und erweitern, und da ich mit Python vertraut bin und jeder wirklich schnell Python lernen kann, scheint es mir ein Vorteil zu sein. Ich kenne auch C und schreibe Python-Erweiterungen in C, also nehme ich an, dass ich eines Tages, wenn ich eine benötige, leicht eine Git-Erweiterung in C schreiben könnte.

Benutzerfreundlichkeit ist nicht einfach zu quantifizieren. Es ist da und ich denke nicht, dass es ganz subjektiv ist, aber wir haben keine guten objektiven Messtechniken. Was wären die Einheiten für die Benutzerfreundlichkeit? Milli-iPods?

Ich bin nicht so parteiisch, dass ich zu 100% pro-mercurial und zu 100% anti-git bin. Ich fühle mich jetzt auf Mercurial wohler, unter Windows und Linux, und wenn ich anfange, mehr auf dem Mac zu arbeiten, gehe ich davon aus, dass ich versuchen werde, bei XCode + GIT zu bleiben.

Update 2013: Ich habe jetzt Mercurial AND GIT lange genug verwendet, um einige Funktionen zu finden, die Git gerne hätte, z. B. diese Frage zu Zusammenführungsstrategien. Wirklich Git ist erstaunlich, wenn auch schwer zu lernen und manchmal unglaublich komplex.

Warren P
quelle
7

Es gibt ein paar Dinge, die IMO wahrscheinlich neue Benutzer von Git abschrecken werden:

  1. Die Git-Kultur ist mehr auf die Befehlszeile ausgerichtet. Obwohl sich beide Tools zu sehr auf die Befehlszeile konzentrieren (wie ich bereits mehrfach gesagt habe, sind Befehlszeilenanweisungen zwar mächtiger und fließender, aber keine gute Marketingstrategie ), ist dies bei Git viel häufiger der Fall. Während Mercurial ein De-facto-Standard-GUI-Tool in TortoiseHg hat, das sogar die Standard-Downloadoption für Windows-Benutzer auf der Mercurial-Homepage ist, hat Git mehrere konkurrierende GUI-Frontends (TortoiseGit, Git Extensions, Gitk usw.), die nicht gut beworben werden auf der Git-Website, und die sind sowieso alle ein komplettes Problem. (Schwarzer Text auf roten Etiketten? Komm schon, TortoiseGit, du kannst es besser machen!) In der Git-Community herrscht außerdem eine weit verbreitete Meinung vor, dass Benutzer von GUI-Tools keine richtigen Software-Entwickler sind.

  2. Git verfügt über mehrere Standardeinstellungen, die für fortgeschrittene Benutzer durchaus sinnvoll sind, aber wahrscheinlich überraschend sind, wenn nicht einschüchternd für neue Benutzer. Zum Beispiel ist es aggressiver, Aufgaben wie das Zusammenführen zu automatisieren (zum Beispiel führt Git Pull, wo immer möglich, automatisch zusammen und schreibt es fest). Es gibt Gründe für ein vollautomatisches Zusammenführen, aber die meisten unerfahrenen Benutzer haben Angst vor dem Zusammenführen und müssen die Möglichkeit erhalten, Vertrauen in ihre Tools zu gewinnen, bevor sie ihre volle Leistungsfähigkeit für ihren Quellcode entfalten können.

  3. Dokumentation und Komplexität:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    
Marmeladenkuchen
quelle
3
Eigentlich bevorzuge ich eine Hilfe, die 912 Zeilen lang ist, gegenüber einer Hilfe, die 64 Zeilen lang ist.
Dysaster
10
Eigentlich bevorzuge ich eine Benutzeroberfläche, die so intuitiv und nahtlos ist, dass Sie überhaupt keine Hilfe benötigen.
Jammycakes
2
Ich möchte sowohl die GUI als auch die Hilfe. :) Was mir intuitiv erscheint, ist ein Durcheinander für jemand anderen.
Dysaster
1
Klar, aber wenn Hilfe nötig ist, sollte es einfach zu befolgen sein.
Jamycakes
3
Ich habe an eine neue Analogie gedacht; Git ist wie C ++ (sorry Linus!) Und Mercurial ist wie Pascal. Was in Pascal (oder Mercurial) implizit und nur in einer Richtung möglich ist, kann in C ++ (und Git) auf neunzehn verschiedene Arten explizit erfolgen. Einige Leute bevorzugen Powertools mit mehr Tasten und Hebeln, und Git ist das.
Warren P
3

Eine Sache, an die ich denken kann, ist

git add .
git commit -am "message"

gegen

hg ci -Am "message"

git commit -afügt keine neu erstellten Dateien hinzu, hg ci -Awas bedeutet, dass etwas, das zwei Befehle mit git erfordert, mit einem Befehl in Mercurial ausgeführt werden kann. Andererseits bedeutet "weniger Tippen" nicht unbedingt "benutzerfreundlicher".

Zhehao Mao
quelle
11
Ich stelle häufig fest, dass das automatische Hinzufügen neuer Dateien in meinem Workflow eigentlich unerwünscht ist. Ich habe es vorgezogen, wie es git commit -aeinfach funktioniert, weil es einfacher ist zu kontrollieren, was für ein bestimmtes Commit hinzugefügt wird und was nicht. (Eigentlich ist es nicht ungewöhnlich, dass ich für jeden einzelne Pfadnamen spezifiziere svn ci, um zu vermeiden, dass einem Commit Material ohne Bezug hinzugefügt wird.)
greyfade
3
Fair genug, aber ich glaube, dass hg ciohne die -AFlagge das Äquivalent von tut git commit -a. Ich habe viel mehr git als hg verwendet, daher bin ich mir nicht 100% sicher.
Zhehao Mao
Ich habe geprüft, hg ci== git commit -a.
Zhehao Mao
Wenn Sie jedoch bestimmte Dateien mit hg commit angeben, können Sie das Einlesen unerwünschter Dateien vermeiden. In den seltenen Fällen, in denen ich diese Steuerung möchte, finde ich, dass dies gut funktioniert.
Alex Miller
1
warum würdest du "git hinzufügen" und dann "git commit -am"? Wäre nicht alles bereits in den Index aufgenommen?
Jacobangel
3

Denn es ist.

Git enthüllt weit mehr seiner Eingeweide als Quecksilber. Sie können Quecksilber gerne innerhalb weniger Minuten nach dem Aufnehmen verwenden, aber ich finde es immer noch sehr schwierig, mich mit dem Schwachsinn auseinanderzusetzen, nachdem ich ein paar Monate damit gerungen habe (ich habe in den letzten Monaten nur sehr wenig getan, außer zu versuchen, Schwachsinn zu lernen) ). Ich benutze sowohl von der Kommandozeile als auch meistens unter Linux, so dass dies nicht nur eine Abneigung gegen die Kommandozeilenschnittstelle ist.

Ein einfaches Beispiel sind die relativ wenigen Flags und Befehlszeilenargumente, die für mercurial im Vergleich zu git benötigt werden. Der Staging-Bereich und das Verhalten des Befehls add in git erhöhen außerdem die Komplexität, als erforderlich ist. Das Trio von Zurücksetzen, Auschecken und Zurücksetzen und deren mehrfachen Permutationen fügt eine enorme Komplexität hinzu, die ziemlich unnötig war, als Sie die unkomplizierte Natur des Zurücksetzens und Aktualisierens auf mercurial erlebten.

Ich stimme mit dem obigen Kommentar auch über Hginit überein , es machte Quecksilber definitiv viel leichter zu verstehen. Gut geschrieben und sehr leicht zu verstehen. Keine der für git geschriebenen Dokumentationen kommt dem nahe. Ich finde das meiste, was von Scott Chacone geschrieben wurde (der die meisten Dokumentationen / Bücher über Git im Alleingang geschrieben hat), besonders verwirrend.

U / min
quelle