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


204

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)


21
Bizarre, je n'ai jamais entendu dire que Mercurial était aussi facile. J'ai trouvé plus de documentation sur Git (peut-être une perception) alors je l'ai appris.
Nic

16
Parce qu'il a été fabriqué par Linus?
Job

124
Ici, je trouvais Mercurial plus facile à utiliser que Git car, en tant qu’utilisateur Windows, je me sentais bien accueilli par Mercurial et traité comme un monstre et un perdant par Git. Je sais que je suis un logiciel anthropomorphisant, et que les deux sont parfaitement capables d’être utilisés sous Windows, mais c’est l’impression qu’ils dégagent.
Carson63000


11
Je me demande combien de personnes utiliseraient Git si Github n'existait pas ou ne comportait pas autant de projets de grande envergure.
Chris S

Réponses:


240

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.


6
Commentaires: les commentaires servent à demander des éclaircissements et non à prolonger la discussion. Si vous avez une solution, laissez une réponse. Si votre solution est déjà publiée, veuillez la revérifier. Si vous souhaitez discuter de cette question avec d'autres personnes, utilisez le chat . Voir la FAQ pour plus d'informations.

1
IntelliJ IDEA et Xcode 4 intègrent merveilleusement Git sur leurs plates-formes respectives. Pour les tâches quotidiennes, vous n’avez jamais à utiliser la ligne de commande.

4
Je voudrais ajouter que tortoiseGIT est beaucoup mieux maintenant lorsque vous souhaitez utiliser GIT sur Windows. Vous devez toujours gérer les clés SSL et le processus d’installation n’est pas simple, mais une fois terminé, cela fonctionne facilement.
Arkh

2
Extensions Git Personnellement, je trouve qu'il est beaucoup plus facile de naviguer et de travailler que TortoiseHG sous Windows, et je n'ai utilisé qu'une seule ligne de commande avec git.
KallDrexx

1
Cette ligne me laisse un peu perplexe: "MinGW n'est pas une invite de commande Windows, mais une action différente. Il est fou que ce soit la seule façon de travailler avec Git." J'utilise l'installation de msysgit et l'option 2, pour exécuter à partir de la ligne de commande Windows. Ça fonctionne bien. Quelques éléments ne fonctionnent pas (comme le curseur, un caractère de continuation de ligne sous DOS), mais il existe des alternatives à celles (comme le tilde) qui fonctionnent correctement. Je ne suis pas un passionné de la ligne de commande (ou du moins je ne l'étais pas avant d'avoir commencé à apprendre à utiliser Git), mais utiliser Git avec la ligne de commande est très simple. Est-ce que je manque quelque chose?
Kyralessa

80

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.


73
Ainsi, Mercurial ne cache que les fonctionnalités avancées, tandis que GIT masque toutes les fonctionnalités ... ;-)
épouvantable du

4
Git ne possède plus de puissance. Par exemple, il n'y a pas d'équivalent à HEAD ~ 1 de git . Mercurial a p (x) qui s'étend à travers les branches, quelle utilité. Il n'y a pas de stade dans Hg. Toutes les branches doivent être poussées lorsque vous appuyez. Mercurial n’est tout simplement pas aussi flexible, même avec tous les plugins comme histedit, shelf et rebase. La ligne de commande de Git est également meilleure, elle donne des conseils à l'utilisateur, contrairement à Mercurials. Je suis obligé d'utiliser ce DVCS légèrement handicapé au travail et je suis arrivé dans des situations où Mercurial n'a pas le pouvoir de faire ce que je veux.
Keyo

22
@Keyo: Mercurial a ~, voir revsets . Il n'a pas de zone de transfert, mais vous pouvez l'imiter avec MQ, qui est tellement plus puissant. Apprenez à utiliser cet outil plutôt que de vous en tenir à ce que vous savez de git, cela vous rapportera.
Idan K

22
@Keyo: Vous n'avez pas besoin de pousser toutes les branches avec Mercurial lorsque vous appuyez. Vous pouvez pousser une branche spécifique ( hg push --branch BRANCH) ou une révision spécifique ( hg push --rev REV). S'il vous plaît voir hg help pushpour plus d'options.
Regent

1
Pour votre information, vous pouvez obtenir un sous-ensemble considérable de la zone de stockage intermédiaire en utilisant l' extension d'enregistrement . OTOH, je pense que l' extension shelve (inspirée de la commande "shelve" de Baazar et proche de "git stash") sert bien mieux la plupart des objectifs de l'utilisation de la zone de transit.
brandizzi

47

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.

6
+1 pour mentionner l'index; Je pense que l'indice et ses interactions sont la chose qui rend git plus difficile à apprendre que Mercurial.
Sean McMillan

18
Les hgéquivalents aux gitbranches sont en réalité appelés bookmarks. Autant que je sache, les hgsuccursales n'ont pas d'équivalent en git.
Hank Gay

6
Je suis dans la même situation, avec Mercurial au travail et git à la maison. Les branches Mercurial sont plutôt agaçantes pour moi, j'aime bien avoir des branches privées et les pousser quand bon me semble. Mercurial me force à utiliser des étagères ou des pensions supplémentaires. Les numéros de révision sont stupides, donnez-moi le hachage. La scène est géniale, ça me manque. Je manque vraiment le pouvoir de git. J'ai fait pas mal de choses avec quelques plugins mais le branchement m'énerve vraiment.
Keyo

6
@Keyo - D'après mon expérience, la création de gitbranches est un sous-ensemble de la hgcréation de branches. Dans hgvous pouvez avoir à la fois des branches nommées et non nommées (topologiques) et même gérer des branches sans nom de la même manière que l’ gitutilisation de signets. Je n'ai jamais vraiment vu le point dans la zone de rassemblement. Je préférerais de beaucoup mettre de côté les modifications non désirées, puis s’assurer que mon code compile et termine mes tests avant de le valider. Je peux alors me défaire et continuer. En outre, "Massaging Hunks" (p90 +) de Charles Bailey me fait peur * 8 ': accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
Mark Booth

7
@Keyo: Dans Mercurial, les branches privées sont appelées «signets»: mise à jour de la révision racine,, hg bookmark keyo-stufffaire des choses hg commit, puis éventuellement hg push -B keyo-stuff. Si vous n'aimez pas les numéros de révision, ne les utilisez pas; Mercurial acceptera un hachage partout où il acceptera un numéro de révision, je pense. Je dois dire que vos commentaires dénigrent Mercurial pour un manque de fonctionnalités qu’il a en fait considérées comme ignorantes et un peu agressives; vous ne faites pas beaucoup de bien pour le stéréotype des utilisateurs de Git!
Tom Anderson

29

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.


+1 pour "moins de wtf / minute" -1 pour "c'est très subjectif". Ce n'est pas très subjectif ... Je ne sais pas pourquoi les gens pensent encore que les différences entre l'assurance-chômage sont subjectives. Si je prends mercurial et que md5 hasch ses commandes, vous ne diriez pas que certaines personnes pourraient trouver un hachage md5 plus intuitif que l'original, n'est-ce pas? (J'espère que non). La même chose est vraie de Git. Git n’est plus facile que mercurial si votre expérience avec git est considérablement plus importante que mercurial.
weberc2

17

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.


7
Nan. Il y a trop d'autres étapes de workflow pour que vous l'appeliez simplement "syntaxe différente". Pour utiliser Git, vous devez comprendre le modèle sous-jacent que vous manipulez et connaître l'état de l'index git. Dire SQL et Pascal sont deux syntaxes différentes car la même chose serait également fausse. Git est un système de version de contenu de système de fichiers doté de fonctionnalités DVCS. Mercurial est un DVCS qui ne gère pas toutes les opérations de gestion de version de contenu de système de fichiers, mais uniquement le sous-ensemble requis par les utilisateurs de DVCS.
Warren P

9

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.


7

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
    

3
En fait, je préfère une aide de 912 lignes à une aide de 64.
Dysaster

10
En fait, je préfère une interface utilisateur tellement intuitive et transparente que vous n'avez pas besoin d'aide en premier lieu.
jammycakes

2
Je veux à la fois l'interface graphique et l'aide. :) Ce qui me semble intuitif, c'est un gâchis pour quelqu'un d'autre.
Dysaster

1
Bien sûr, mais lorsque l’aide est nécessaire, elle doit être facile à suivre.
jammycakes

3
J'ai pensé à une nouvelle analogie; Git est comme C ++ (désolé Linus!) Et Mercurial est comme Pascal. Ce qui est implicite et ne peut être fait que d'une manière en Pascal (ou Mercurial) peut être fait de manière explicite, dix-neuf façons différentes en C ++ (et Git). Certaines personnes préfèrent les outils électriques avec plus de boutons et de leviers, et c'est Git.
Warren P

3

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".


11
Je trouve souvent que dans mon flux de travail, l'ajout automatique de nouveaux fichiers est en réalité indésirable. Je viens de préférer comment git commit -afonctionne simplement parce que cela permet de contrôler plus facilement ce qui est ajouté ou non pour un commit donné. (Il n'est en fait pas inhabituel pour moi de spécifier des noms de chemin d'accès individuels pour svn ciéviter d'ajouter des éléments non liés à un commit.)
greyfade

3
Très bien, mais je crois que hg cisans le -Adrapeau l’équivalent de git commit -a. J'ai utilisé git beaucoup plus que hg, donc je ne suis pas sûr à 100%.
Zhehao Mao

J'ai vérifié, hg ci== git commit -a.
Zhehao Mao

mais si vous spécifiez des fichiers spécifiques avec hg commit, vous pouvez éviter d’en extraire ceux que vous ne voulez pas. Dans les cas peu fréquents où je veux ce contrôle, je trouve que cela fonctionne bien.
Alex Miller

1
pourquoi voudriez-vous "ajouter git." et ensuite "git commit -am"? Tout ne serait-il pas déjà ajouté à l'index?
jacobangel

3

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.