Git est un système de gestion de code source utilisé par les développeurs du noyau Linux, entre autres. Le logiciel a été développé initialement par Linus Torvalds pour remplacer Bitkeeper devenu payant (arrêt de la distribution d'une version gratuite pour être précis).
Cette nouvelle version amène de nombreux changement, décrits dans la suite de l'article.
![[en]](../images/en.png)
L'annonce (739 hits)-
Téléchargement (343 hits)
-
Documentation de GIT (695 hits)
> Lire la dépêche (22 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #704714.
Run by 
Cette page a été générée par Templeet en 0.0581s (dont 0.0095 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Mercurial, le fils caché de GIT grandit lui aussi
Excusez mon titre foireux, c'est lundi :-)
Je voulais profiter de cette news sur GIT pour parler de son cousin Mercurial. Pour ceux qui ne connaissent pas, Mercurial est né suite à la publication un peu hative de GIT par Linus Torvalds. Matt Mackal trouvait que GIT utilisait des raccourcis techniques un peu gros et décida de coder un prototype de SCM en python pour tenter de faire quelque chose de plus propre. Voilà coté historique. Dans la pratique les deux s'utilisent globalement de la même façon. Mercurial possède un meilleur support windows que son homologue.
Donc Mercurial 0.8.1 est sorti il y a de çà 2 semaines en apportant un lot assez important de fonctionnalités.
Nouvelles extensions:
- mq: gestion de queue de patchs. S'inspire du workflow d'un quilt, mais on garde les avantages d'avoir ses sources sous contrôle d'un SCM
- mail: où l'art d'envoyer ses changements via email sans se soucier de rien.
- gpg: permet de signer chaque changeset pour les gens qui commit, et de façon symmétrique, de vérifier les signatures pour ceux qui pull les changesets.
- hgbisect: extension qui aide a retrouver le changeset coupable d'un bug identifié sur un intervalle de révisions donné.
Nouvelles fonctionnalités:
- La sortie de plusieurs commandes (dont 'log') peut être patronnée (templatée), de la même façon que les pages web de la commande serve. On peut donc par exemple générer des ChangeLog dans un format propre à son projet.
- Possibilité d'utiliser la commande 'incoming' sur des repositories distants et ainsi savoir quels changements seraient rapatriés en local.
...
Bugfix:
- Quelques bugs sous windows, principalement des différences de comportement de python sous les environnements Unix et Windows.
- ... hg log pour les courageux :-)
Et le développement continue... la future version intègre déjà un nouveau format de repository qui peut alléger leur taille jusqu'à 40%, en utilisant deux fois moins d'inodes... ce changement a pour effet de minimiser la mémoire requise à pas mal d'endroits, d'accélerer certaines commandes... bref que du bon. Une commande 'archive' est arrivée pour faire des export des sources très simplement en zip, targz, tarbz2...
Enfin je veux pas trop vampiriser la news sur GIT pour promouvoir Mercurial, mais que tous ceux qui souhaitent utiliser GIT, testent aussi Mercurial. Mercurial est souvent plus "propre" que GIT, de plus il est portable... user friendly et son poil brille plus fort que celui de GIT :-)
[^]Re: Mercurial, le fils caché de GIT grandit lui aussi
Notons aussi que Mercurial va devenir le SCM distribué pour le developement de OpenSolaris après une review de Bazaar-NG, Git et Mercurial:
http://mail.opensolaris.org/pipermail/tools-discuss/2006-Apr(...)
[^]Re: Mercurial, le fils caché de GIT grandit lui aussi
Soyons honnêtes et clairs :
* StGit propose une gestion de queue de patch depuis longtemps
* La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
* Bisect provient directement de Git, c'est une belle et vraie invention de Linus
Bref, les nouveautés de Mercurial sont surtout du rattrappage de retard. Ce qui n'enlève rien à leur mérite, mais on a tendance à confondre nouveauté et innovation, surtout quand il s'agit de fonctionnalités peu familières.
Ceci dit, continuons à être honnêtes :
* Mercurial est très sympa a utiliser sous Windows
* Mercurial a effectivement le poil plus brillant
* Mercurial est plus avancé d'un point de vue internationalisation (l'infrastructure est là, reste à traduire)
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).
Niveau projets connus, MoinMoin est passé ce week-end d'Arch à Mercurial, de préférence à Git, ce qui est purement logique (tous deux écrits en Python, et le wiki de Mercurial, c'est MoinMoin -- affinités fortes).
Du côté de Git, outre X.org déjà mentionné, il y a également Wine, qui a un des sources codes les plus bourrins que je connaisse (la compilation nécessite plus d'un giga d'espace disque). Bref, Git intéresse les gros projets.
[^]Re: Mercurial, le fils caché de GIT grandit lui aussi
il y a également Wine, qui a un des sources codes les plus bourrins que je connaisse (la compilation nécessite plus d'un giga d'espace disque)
Et OpenOffice reste avec son CVS... (plus de 5Go d'espace disque pour compiler, wine fait petit joueur à côté)
[^]Re: Mercurial, le fils caché de GIT grandit lui aussi
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
Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
Bientôt, on pourra compiler du code Python...
http://codespeak.net/pypy/dist/pypy/doc/news.html
Y'a des trucs pour traduire du code python en C, mais aussi en assembleur, Java (!), Javascript (je suis perplexe, j'ai pas trop contrôlé...). J'ai aussi vu des dossiers smalltalk et llvm dans leur SVN...
[^]Monotone, le père spirituel de git mûrit lui aussi
Hop, moi aussi je profite de la news pour rappeler que monotone http://www.venge.net/monotone/ existe toujours. La version 0.26 est sortie il y a 2 semaines.
Linus s'est beaucoup inspiré de monotone pour l'architecture de git. En fait la première version de git utilisait pratiquement le même façon que monotone d'organiser les données. Ça a un peu divergé depuis mais les principes sont les mêmes.