Pourquoi Mercurial est-il considéré comme plus facile que Git?

Lorsque je regarde les comparaisons, il me semble qu’il pourrait y avoir un mappage 1: 1 entre leurs jeux de caractéristiques. Pourtant, une déclaration souvent citée est que "Mercurial est plus facile". Quelle est la base de cette déclaration? (si seulement)

Exemple: disons que vous souhaitez modifier le nom d'utilisateur de tous vos commits précédents. J'ai eu besoin de le faire plusieurs fois pour diverses raisons.

Version Git

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

Version Mercurial:

auteurs.convert.list:

<oldname>=<newname>

Ligne de commande:

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

Maintenant, lequel semble plus facile à utiliser?

Note: J'ai passé 2 ans à travailler uniquement avec Git, donc ce n'est pas un discours "je déteste ça, je ne l'ai pas eu en 2 secondes".

Pour moi, c'est la facilité d'utilisation. Git est très orienté Linux avec une manière de faire les choses sous Linux. Cela signifie une ligne de commande, des pages de manuel, et le découvrir vous-même. Son interface graphique était très médiocre (remarque: je me base sur msysGit il y a environ un an), qui semblait tout simplement me gêner. Je pouvais à peine l'utiliser

La ligne de commande était pire. En tant que programme orienté Linux, il était très difficile à utiliser sous Windows. Au lieu d'un port natif, ils ont simplement enveloppé git avec MinGW (Think cygwin), ce qui rendait le travail beaucoup plus difficile. MinGW n'est pas une invite de commande Windows et agit simplement différemment. C'est fou que ce soit la seule façon de travailler avec Git. Même sous Linux, le seul moyen semblait fonctionner avec une ligne de commande directe. Des projets comme RabbitVCS ont aidé certains, mais n'étaient pas très puissants.

L’approche orientée ligne de commande et le fait que ce soit un programme Linux signifie que presque tous les guides d’aide, la documentation d’aide et les questions relatives au forum / AQ reposaient sur l’exécution de commandes monstrueuses comme ci-dessus. Les commandes SCM de base (commit, pull, push) ne sont pas aussi complexes, mais leur complexité augmente de manière exponentielle.

Je déteste aussi le seul endroit où de nombreux utilisateurs de git OSS semblent traîner: Github. Lorsque vous accédez pour la première fois à une page github, cela vous claque avec tout ce que vous pouvez éventuellement faire. Pour moi, une page git de projets a l' air chaotique, effrayante et trop puissante. Même l'explication de ce qu'est le projet est poussée au fond. Github blesse vraiment les gens qui n'ont pas déjà un site complet. Son suivi des problèmes est également terrible et déroutant. Surcharge de fonctionnalité.

Les utilisateurs de Git semblaient aussi être très culte. Les utilisateurs de Git semblent toujours être ceux qui commencent des "guerres saintes" pour lesquelles le DVCS est meilleur, ce qui oblige ensuite les utilisateurs de Mercurial à se défendre. Des sites comme http://whygitisbetterthanx.com/ affichent de l'arrogance et une mentalité proche de "Utilisez mon logiciel ou mourez". Bien souvent, je suis allé chercher de l'aide pour ne pas connaître X, utiliser X au préalable, Windows, etc.

Mercurial, en revanche, semble aller dans le sens d’une approche plus douce. Leur propre page d'accueil semble beaucoup plus conviviale pour les nouveaux utilisateurs que celle de Git . Dans une simple recherche sur Google, le 5ème résultat est TortoiseHg, une très belle interface graphique pour Mercurial. Toute leur approche semble être la simplicité d'abord, le pouvoir plus tard.

Avec Mercurial, je n'ai pas d'absurdité SSH (SSH est un enfer sous Windows), je n'ai pas de commandes stupidement complexes, je n'ai pas d'utilisateur culte à suivre, je n'ai pas la folie. Mercurial fonctionne.

TortoiseHg fournit une interface réellement utilisable (bien que, dernièrement, elle semble se développer) qui fournit des fonctionnalités utiles. Les options sont limitées à ce dont vous avez besoin, en supprimant le fouillis et les options rarement utilisées. Il fournit également de nombreux défauts par défaut

Mercurial, étant très amical avec les nouveaux arrivants, était très facile à prendre en charge. Même certains des sujets les plus complexes, tels que le modèle de création de branches et l'édition d'historique, étaient très faciles à suivre. J'ai ramassé Mercurial rapidement et sans douleur.

Mercurial fonctionne également pour la première fois avec peu d’installation. Sur n’importe quel système d’exploitation, je peux simplement installer TortoiseHg et bénéficier de toutes les fonctionnalités souhaitées (principalement des commandes de menu contextuel) sans avoir à rechercher différents Guis. Il manque également la configuration de SSH (la moitié des guides disent d’utiliser Putty, Plink et Pagent, tandis que l’autre moitié dit d’utiliser ssh-keygen). TortoiseHg prend quelques minutes à configurer tandis que Git prend 30 minutes à une heure avec beaucoup de recherches sur Google.

Enfin, vous avez le dépôt en ligne. L'équivalent de Githubs est BitBucket, qui présente certains des problèmes que j'ai décrits ci-dessus. Cependant, il y a aussi Google Code. Lorsque je me connecte à un projet Google Code , je ne suis pas surchargé de fonctionnalités, je reçois une interface propre et agréable. Google Code est plutôt un combo de sites Web / référents en ligne, ce qui aide réellement les projets OSS n'ayant pas de configuration de site existante. Je serais très à l'aise d'utiliser Google Code comme site Web de mes projets pendant un bon bout de temps, ne construisant un site Web que lorsque cela est absolument nécessaire. Son système de suivi des problèmes est également puissant, s’intégrant parfaitement entre le système de suivi des problèmes presque inutile de Github et la monstruosité de Bugzilla .

Mercurial fonctionne tout simplement, pour la première fois, à chaque fois. Git se met en travers de mon chemin et ne me met en colère que plus je l'utilise.

Git contre Mercurial

On pense généralement que Mercurial est plus simple et plus facile à apprendre que Git. À son tour, il y a souvent la perception que Git est plus flexible et puissant. Cela est dû en partie au fait que Git a tendance à fournir davantage de commandes de bas niveau, mais également au fait que Mercurial, par défaut, a tendance à masquer les fonctionnalités avancées , laissant le soin aux utilisateurs de modifier le fichier de configuration mercurial pour activer les fonctionnalités avancées qui leur plaisent. Cela conduit souvent à penser que les fonctionnalités avancées ne sont pas disponibles dans Mercurial.

Concepts Git

Mercurial s’est toujours davantage concentré sur les aspects d’interface, ce qui en a facilité l’apprentissage à l’origine. Par rapport à Git, une compréhension moins profonde est nécessaire pour utiliser Mercurial de manière utile. À long terme, cette encapsulation a donné à Mercurial la fausse apparence d’être moins puissante et moins fonctionnelle qu’elle ne l’est réellement.

Contexte: J'utilise quotidiennement Mercurial (pour le travail) et Git (pour les projets parallèles et open source). J'utilise principalement des outils textuels avec les deux (pas les IDE) et je suis sur un Mac.

En général, je trouve qu'il est plus facile de travailler avec Mercurial. Quelques choses que je trouve rendent Mercurial plus facile:

1. Manque de l'index. L’index est un outil puissant qui permet de nombreuses fonctionnalités de Git, mais c’est aussi une couche supplémentaire qui ajoute une étape à de nombreuses choses que je fais régulièrement. Le flux de travail de Mercurial ressemble plus à quelque chose comme svn.
2. Numéros de révision au lieu de shas. C’est une petite chose qui, selon moi, facilite énormément le travail quotidien avec Mercurial. Il est bien plus facile de vous envoyer quelques numéros de révision dans votre tête pendant une création de base, une fusion, etc. tout en écrivant une commande, plutôt que de faire la même chose, même avec des shas raccourcis.
3. Branches. L'approche de Git en nommant les commits est puissante et sensiblement différente de celle des autres systèmes de contrôle de version. Cela facilite beaucoup certaines choses. Je trouve que l'approche de Mercurial correspond un peu mieux à la réflexion et facilite la compréhension visuelle de l'historique de la branche. Cela peut juste être une préférence.

Ceci est très subjectif et dépend d’une personne à l’autre, mais oui, je dirais que, pour une personne complètement nouvelle en VCS ou une personne venant d’un VCS de la "vieille école", Mercurial semblera plus facile.

Par exemple, l'ajout de fichiers, la non-existence de l'index dans Hg, la facilité de revenir à une ancienne révision et la création d'une branche à partir de là (il suffit de mettre à jour et de valider) sont des exemples parmi les plus "évidents". Maintenant, la plupart des fonctionnalités d'un système peuvent être émulées dans un autre et inversement, mais cela nécessite quelques connaissances de Git, tandis que dans Mercurial, les valeurs par défaut (si vous me permettez de les appeler ainsi) sont plutôt "conviviales". Ces petites choses - le commutateur ici et là, le comportement non évident dans une commande, etc. - ces choses s’additionnent, et à la fin, un système semble plus facile à utiliser que l’autre.

Juste pour compléter la réponse; J'utilise git, mais lorsque je recommande un VCS à une personne "nouvelle", je recommande presque toujours Mercurial. Je me souviens que, lorsque cela m'est arrivé pour la première fois, cela me semblait très intuitif. D'après mon expérience, Mercurial produit moins de wtf / minute que Git.

Je pense que c'est aussi simple que cela: Mercurial a une syntaxe plus familière (en particulier pour les utilisateurs de SVN) et est assez bien documentée. Une fois que vous vous êtes habitué à la syntaxe Git, vous la trouverez aussi facile à utiliser que n'importe quoi d'autre.

Les perceptions pourraient changer avec le temps, à ce sujet. Mercurial est très bien conçu, tout comme Git. Mercurial semble être plus facile à apprendre (du moins c'était pour moi), et il y a eu des difficultés que j'ai rencontrées à Git, pour lesquelles je n'ai pas de parallèle dans Mercurial. J'ai essayé d'apprendre Python et Ruby et je suis allé plus loin, plus vite avec Python. Cela ne signifie pas que Python est toujours et partout meilleur que Ruby, ou même que c'est meilleur pour moi. C'est juste ce que j'ai appris et coincé avec. Les programmeurs font souvent des guerres saintes par préférence personnelle. D'autres êtres humains le font aussi.

Je suis un utilisateur de Mercurial qui essaie de garder l'esprit ouvert à propos de Git et j'avoue librement que ce n'est pas "devenu mon nouveau truc préféré" au même titre que Mercurial. Je pense cependant que Git est vraiment très sympa.

Un exemple contraire à la complexité GIT / mercurial: le support Nice GIT est intégré à XCode, sur Mac. XCode avec Mercurial moins facile à utiliser que GIT.

Mon expérience avec GIT a été que je suis confus et perdu et que je dois consulter davantage la documentation tout en l’utilisant. Je crois que beaucoup de documentation a été écrite, mais rien ne m'a permis de le "grok". Deuxièmement, je peux modifier et étendre Mercurial facilement en Python, et comme je suis un adepte de Python, et comme tout le monde peut apprendre le python rapidement, cela me semble un avantage. Je connais aussi C et écris des extensions Python en C, donc je suppose qu’un jour, si j’en avais besoin, je pourrais facilement écrire une extension Git en C.

La facilité d'utilisation n'est pas quelque chose de facile à quantifier. C'est là, et je ne pense pas que cela soit entièrement subjectif, mais nous n'avons pas de bonnes techniques de mesure objective. Quelles seraient les unités pour la facilité d'utilisation? Milli-iPods?

Je ne suis pas assez partisan pour être 100% pro-mercuriel et 100% anti-git. Je suis plus à l'aise maintenant sur Mercurial, sous Windows et sous Linux, et lorsque je commence à travailler davantage sur Mac, je m'attends à ce que j'essaie de m'en tenir à XCode + GIT.

Mise à jour 2013: J'utilise désormais Mercurial ET GIT assez longtemps pour trouver certaines fonctionnalités que j'aimerais avoir avec Git, telles que cette question sur les stratégies de fusion. Vraiment, Git est incroyable, même s’il est difficile à apprendre et parfois extrêmement complexe.

IMO risque de dissuader de nouveaux utilisateurs d'utiliser Git:

1. La culture Git est plus centrée sur la ligne de commande. Bien que les deux outils aient tendance à trop se concentrer sur la ligne de commande (comme je l’ai dit à plusieurs reprises, les instructions en ligne de commande peuvent être puissantes et plus fluides, mais ce n’est pas une bonne stratégie marketing ), c’est beaucoup plus le cas avec Git. Alors que Mercurial dispose d’un outil graphique standard de facto dans TortoiseHg, qui est même l’option de téléchargement par défaut pour les utilisateurs Windows sur la page d’accueil de Mercurial, Git possède plusieurs interfaces graphiques concurrentes (TortoiseGit, Git Extensions, gitk, etc.) qui ne sont pas bien annoncées. sur le site Web de Git, et qui sont tous une horreur complète de toute façon. (Texte noir sur les étiquettes rouges? Allez, TortoiseGit, vous pouvez faire mieux que ça!) Il existe également une attitude beaucoup plus répandue dans la communauté Git selon laquelle les personnes utilisant des outils d'interface graphique ne sont pas de bons développeurs de logiciels.

2. Git a plusieurs paramètres par défaut prêts à l'emploi qui conviennent parfaitement aux utilisateurs avancés, mais qui risquent d'être surprenants, voire intimidants, pour les nouveaux utilisateurs. Par exemple, il est beaucoup plus agressif d'automatiser des tâches telles que la fusion (par exemple, git pull fusionne et valide automatiquement dans la mesure du possible). Des fusions entièrement automatisées sont souhaitables , mais la plupart des utilisateurs inexpérimentés sont terrifiés par la fusion et doivent avoir la possibilité de gagner la confiance en leurs outils avant de libérer pleinement leur pouvoir sur leur code source.

3. Documentation et complexité inhérente:

   $ hg help log | wc -l
   64
   $ git help log | wc -l
   912
   

Une chose à laquelle je peux penser est

git add .
git commit -am "message"

contre.

hg ci -Am "message"

git commit -an’ajoute pas les fichiers nouvellement créés hg ci -A, c’est-à-dire que quelque chose nécessitant deux commandes avec git peut être fait avec une seule commande dans Mercurial. Là encore, "moins de frappe" ne signifie pas nécessairement "plus convivial".

Parce que c'est.

Git expose beaucoup plus de ses tripes que mercurial. Vous pouvez utiliser heureusement Mercurial quelques minutes après l'avoir ramassé, mais je trouve qu'il est encore très difficile de se battre avec Git après quelques mois de lutte (j'ai très peu fait ces derniers mois, à part essayer d'apprendre git ). J'utilise les deux à partir de la ligne de commande et principalement sous Linux, il ne s'agit donc pas simplement d'une aversion pour l'interface de ligne de commande.

Un exemple simple est le nombre relativement faible d'indicateurs et d'arguments de ligne de commande nécessaires pour mercurial par rapport à git. La zone de transfert et le comportement de la commande add dans git ajoute également plus de complexité que nécessaire. Le trio de reset, checkout et revert et leurs multiples permutations ajoute une énorme complexité, ce qui était tout à fait inutile lorsque vous êtes témoin de la nature simple du retour et de la mise à jour de mercurial.

Je suis d'accord avec le commentaire ci-dessus à propos de Hginit , cela a certainement rendu Mercurial beaucoup plus facile à comprendre. Bien écrit et très facile à comprendre. Aucune de la documentation écrite pour git ne s'en approche. Pour ma part, je trouve la plupart de ce qui est écrit par Scott Chacone (qui a écrit à lui seul la plupart des documents / livres sur git) particulièrement déroutant.