Niveau perfs, git et mercurial se valent à peu près. git est un peu plus rapide une fois que le cache est "chaud", alors que Mercurial prends en compte les accès disque, donc, est un peu plus rapide pour le premier accès à des fichiers.
L'import du noyau Linux dans Mercurial, ça n'aurait pas pris quelques années, c'est fait, et maintenu en synchro : http://www.kernel.org/hg/linux-2.6/
Finalement, Mercurial et Git sont assez proches. Comme différences, je dirais :
* Gestion des renomages : Mercurial enregistre les renomages au moment du commit (copy + delete), git les detecte après coup.
* Git est écrit en C, concu pour être scriptable en shell facilement, Mercurial est écrit en Python, conçu pour être extensible via des plugins
* hg est conçu pour être simple (au niveau de l'interface utilisateur, mais aussi un code source petit : 32000 lignes de python), git est conçu pour être puissant et flexible. Si c'est simple, tant mieux, mais ça n'est pas prioritaire.
* "hg commit" prends le contenu des fichiers au moment où on fait le commit. "git commit" prends le contenu des fichiers au moment où on a fait un "git add" pour la dernière fois. C'est très puissant, par exemple pour faire des commits partiels, mais assez déroutant au début (c'est le fameux "index").
* Git a un format de stoquage remarquablement compact (un facteur 10 par rapport à Subversion sur certains projets, par exemple, le repository Linux fait 174Mo avec git, et 463 avec hg), mais il n'est pas utilisé par défaut. Il faut lancer "git gc" de temps en temps pour recompresser le repository.
* "git blame" a quelque chose qu'à ma connaissance personne d'autre ne fait : il detecte les déplacements de code à l'intérieur et à l'extérieur du fichier. Donc, il est capable de dire que telle ligne du fichier toto.c à été au départ commité dans le fichier titi.c à telle ou telle date, ...
Mais :
* Les deux sont très rapides
* Les deux utilisent des checksums pour identifier les révisions (hérités de monotone)
* Les deux fonctionnent avec un repository par arbre de travail, et des push/pull/merge (hérités de BitKeeper paraît-il)
* Les deux ont un moyen de gérer des files de patchs (mq et stgit, mais je connais pas bien)
* Les deux ont une commande pour réappliquer une branche sur un autre (rebase et transplant)
...
Bref, il y a des différences entre les deux, mais c'est difficile de dire si l'un est meilleur que l'autre. Je crois que c'est surtout une question de goût. Perso, je n'ai pas encore fait mon choix définitif.
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 7.
Niveau perfs, git et mercurial se valent à peu près. git est un peu plus rapide une fois que le cache est "chaud", alors que Mercurial prends en compte les accès disque, donc, est un peu plus rapide pour le premier accès à des fichiers.
L'import du noyau Linux dans Mercurial, ça n'aurait pas pris quelques années, c'est fait, et maintenu en synchro : http://www.kernel.org/hg/linux-2.6/
Finalement, Mercurial et Git sont assez proches. Comme différences, je dirais :
* Gestion des renomages : Mercurial enregistre les renomages au moment du commit (copy + delete), git les detecte après coup.
* Git est écrit en C, concu pour être scriptable en shell facilement, Mercurial est écrit en Python, conçu pour être extensible via des plugins
* hg est conçu pour être simple (au niveau de l'interface utilisateur, mais aussi un code source petit : 32000 lignes de python), git est conçu pour être puissant et flexible. Si c'est simple, tant mieux, mais ça n'est pas prioritaire.
* "hg commit" prends le contenu des fichiers au moment où on fait le commit. "git commit" prends le contenu des fichiers au moment où on a fait un "git add" pour la dernière fois. C'est très puissant, par exemple pour faire des commits partiels, mais assez déroutant au début (c'est le fameux "index").
* Git a un format de stoquage remarquablement compact (un facteur 10 par rapport à Subversion sur certains projets, par exemple, le repository Linux fait 174Mo avec git, et 463 avec hg), mais il n'est pas utilisé par défaut. Il faut lancer "git gc" de temps en temps pour recompresser le repository.
* "git blame" a quelque chose qu'à ma connaissance personne d'autre ne fait : il detecte les déplacements de code à l'intérieur et à l'extérieur du fichier. Donc, il est capable de dire que telle ligne du fichier toto.c à été au départ commité dans le fichier titi.c à telle ou telle date, ...
Mais :
* Les deux sont très rapides
* Les deux utilisent des checksums pour identifier les révisions (hérités de monotone)
* Les deux fonctionnent avec un repository par arbre de travail, et des push/pull/merge (hérités de BitKeeper paraît-il)
* Les deux ont un moyen de gérer des files de patchs (mq et stgit, mais je connais pas bien)
* Les deux ont une commande pour réappliquer une branche sur un autre (rebase et transplant)
...
Bref, il y a des différences entre les deux, mais c'est difficile de dire si l'un est meilleur que l'autre. Je crois que c'est surtout une question de goût. Perso, je n'ai pas encore fait mon choix définitif.