Cette réponse n'a rien de trollesque... si ton post visait à préciser que toutes ces fonctionnalitées étaient présentes dans GIT, il est vrai que j'aurais pu le mentionner dans la mesure où je suis l'évolution des deux projets sur leurs MLs respectives.
Donc je te reprend sur les quelques points pour apporter des précisions:
>StGit propose une gestion de queue de patch depuis longtemps
La gestion n'est pas totalement identique. Mais la palme de la gestion de patchs revient dans ce cas à Quilt de Andrew Morton dont StGit et Mq sont des copies fonctionnelles qui profitent des couches SCM fournies par Git et Mercurial.
>La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
Tout à fait vrai. Linus a toujours aimé avoir des outils de gestion de patchs au format mbox (format historique des emails sous unix). Il est donc tout à fait normal qu'il l'ait implémenté dès le départ dans GIT...
>Bisect provient directement de Git, c'est une belle et vraie invention de Linus
Cette fonctionnalité vise surtout à formaliser par du code une pratique très couramment utilisée par tous ceux qui recherchent les bugs dans le noyau. L'algorithme est une simple dichotomie sur l'intervalle de revisions identifié comme celui qui introduit le bug.
>Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).
Bah oui, mais Mercurial n'a pas eu de Linus Torvalds à sa tête. Et pour un projet, un grand nom comme Linus Torvalds, ça donne envie de s'y pencher... Surtout vu comme GIT a été présenté lors de son officialisation: "GIT remplaçant de BitKeeper pour la gestion des sources de noyau". Il est toujours plus agréable d'associer ses contributions à des projets de renom.
<malife et avis perso>
Moi ce qui m'avait attiré vers Mercurial, c'était la démarche constructive de Matt Mackal, qui essayait de montrer à Linus ses erreurs. Linus refusait d'écouter les arguments avancés. Linus a monopolisé les forces de dev autour d'un projet qui techniquement ressemble plus à un hack qu'à un vrai programme pensé et construit dans les règles de l'art. Ce n'est pas une critique gratuite et trollesque, mais GIT, c'est écris en C pour le coeur, perl, python et Posix Sh pour les porcelains... ca utilisait historiquement rsync qui a mis a genoux kernel.org, puis est passé à un daemon plus malin pour distribuer les changesets manquants entre repositories... le backend fichier tend a espacer dans des répertoires différents des sources qui sont proches lors d'un checkout (dû à l'adressage par hash)... puis remarquant l'inneficacité de la bête lorsque le dictionnaire possède trop d'entrées dans l'index, Linus a eu recours à des packs d'entrées qu'on doit prendre soin de bien maintenir. Ca me fait penser a une idee qui germait dans arch/tla depuis pas mal de temps qui consitait à grouper plusieurs changesets ensembles pour eviter le trashing d'inodes et le parcours inutile du filesystem lors des update et des synchro réseau...
Bref pour moi GIT a le succès qu'on lui connais car il a été démarré par Linus Torvalds... s'il avait été publié par un illustre inconnu, il n'aurait pas tenu la comparaison en terme de fonctionnel avec Monotone, Arch/tla, bazaar 1.x, ou même Darcs, Il n'avait pour lui que sa rapidité à trouver les fichiers changés (man stat(2)).
Matt Mackal a su réfléchir et concevoir quelque chose qui tout en proposant les mêmes fonctionnalités, avait une belle architecture, homogène, lisse. Et même si ce n'est pas codé en C oil of codaz (dédicace GCU Squad), Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
</malife et avis perso>
Donc au final on est globalement d'accord, mais nos points de vue diffèrent car nous sommes fan de deux projets concurrents :-) Que le meilleur gagne !
[^] # Re: Mercurial, le fils caché de GIT grandit lui aussi
Posté par Edouard Gomez . En réponse à la dépêche Sortie de Git 1.3.0. Évalué à 5.
Donc je te reprend sur les quelques points pour apporter des précisions:
>StGit propose une gestion de queue de patch depuis longtemps
La gestion n'est pas totalement identique. Mais la palme de la gestion de patchs revient dans ce cas à Quilt de Andrew Morton dont StGit et Mq sont des copies fonctionnelles qui profitent des couches SCM fournies par Git et Mercurial.
>La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
Tout à fait vrai. Linus a toujours aimé avoir des outils de gestion de patchs au format mbox (format historique des emails sous unix). Il est donc tout à fait normal qu'il l'ait implémenté dès le départ dans GIT...
>Bisect provient directement de Git, c'est une belle et vraie invention de Linus
Cette fonctionnalité vise surtout à formaliser par du code une pratique très couramment utilisée par tous ceux qui recherchent les bugs dans le noyau. L'algorithme est une simple dichotomie sur l'intervalle de revisions identifié comme celui qui introduit le bug.
>Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).
Bah oui, mais Mercurial n'a pas eu de Linus Torvalds à sa tête. Et pour un projet, un grand nom comme Linus Torvalds, ça donne envie de s'y pencher... Surtout vu comme GIT a été présenté lors de son officialisation: "GIT remplaçant de BitKeeper pour la gestion des sources de noyau". Il est toujours plus agréable d'associer ses contributions à des projets de renom.
<malife et avis perso>
Moi ce qui m'avait attiré vers Mercurial, c'était la démarche constructive de Matt Mackal, qui essayait de montrer à Linus ses erreurs. Linus refusait d'écouter les arguments avancés. Linus a monopolisé les forces de dev autour d'un projet qui techniquement ressemble plus à un hack qu'à un vrai programme pensé et construit dans les règles de l'art. Ce n'est pas une critique gratuite et trollesque, mais GIT, c'est écris en C pour le coeur, perl, python et Posix Sh pour les porcelains... ca utilisait historiquement rsync qui a mis a genoux kernel.org, puis est passé à un daemon plus malin pour distribuer les changesets manquants entre repositories... le backend fichier tend a espacer dans des répertoires différents des sources qui sont proches lors d'un checkout (dû à l'adressage par hash)... puis remarquant l'inneficacité de la bête lorsque le dictionnaire possède trop d'entrées dans l'index, Linus a eu recours à des packs d'entrées qu'on doit prendre soin de bien maintenir. Ca me fait penser a une idee qui germait dans arch/tla depuis pas mal de temps qui consitait à grouper plusieurs changesets ensembles pour eviter le trashing d'inodes et le parcours inutile du filesystem lors des update et des synchro réseau...
Bref pour moi GIT a le succès qu'on lui connais car il a été démarré par Linus Torvalds... s'il avait été publié par un illustre inconnu, il n'aurait pas tenu la comparaison en terme de fonctionnel avec Monotone, Arch/tla, bazaar 1.x, ou même Darcs, Il n'avait pour lui que sa rapidité à trouver les fichiers changés (man stat(2)).
Matt Mackal a su réfléchir et concevoir quelque chose qui tout en proposant les mêmes fonctionnalités, avait une belle architecture, homogène, lisse. Et même si ce n'est pas codé en C oil of codaz (dédicace GCU Squad), Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
</malife et avis perso>
Donc au final on est globalement d'accord, mais nos points de vue diffèrent car nous sommes fan de deux projets concurrents :-) Que le meilleur gagne !