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. Les changements:
- tout d'abord, la création de git-cvsserver qui permet d'accéder à un serveur git à partir d'un client CVS classique ;
- la gestion des fichiers diff est maintenant complètement intégrée dans git (plus d'appel à la version GNU de diff) ;
- les dates sont maintenant en notation européenne.
- une interface alternative à svn ;
- 2 interfaces pour emacs ;
- un système pour visionner le code source facilement.
On peut d'ailleurs noter le nombre important de contributeurs dans le changelog, signe révélateur de la bonne santé du projet.
Pour finir, un grand nombre de bug a été corrigé.
Aller plus loin
- L'annonce (3 clics)
- Téléchargement (5 clics)
- Documentation de GIT (8 clics)
# Bugs
Posté par Boa Treize (site web personnel) . Évalué à 10.
(Et puis Git facilite la création d'énormes ChangeLogs exhaustifs, là où avant on avait seulement les points et les bugs les plus marquants.)
Git, en un an, est devenu un gestionnaire de source puissant et très performant, ses fonctionnalités de base sont maintenant bien stabilisées. Je vous invite à le découvrir.
Ceci dit, Git pêche encore sur quelques points : il lui manque un port natif sous Windows (il marche bien sous Cygwin) et une internationalisation, notamment.
Quelques liens vers des points intéressants de la documentation :
Git au quotidien, en une vingtaine de commandes
http://www.kernel.org/pub/software/scm/git/docs/everyday.htm(...)
Le glossaire (Git a quelques termes spécifiques)
http://www.kernel.org/pub/software/scm/git/docs/glossary.htm(...)
[^] # Re: Bugs
Posté par Pinaraf . Évalué à 4.
# Petite faute
Posté par Bob Billy . Évalué à 0.
# Date
Posté par outs . Évalué à 2.
Je connais la notation internationale (2006-04-24), mais européenne je vois pas. Sous google j'ai surtout trouvé des références à l'heure sur 24h plutot que d'utiliser am/pm.
[^] # Re: Date
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
http://www.linux-france.org/article/serveur/psql/Postgres-7.(...)
« ISO
Utilise les dates et heures de style ISO 8601 (YYYY-MM-DD HH:MM:SS). Utilisé par défaut.
(...)
European
Utilise dd/mm/yyyy pour les représentations numériques des dates.
NonEuropean, US
Utilise mm/dd/yyyy pour les représentations numériques des dates.
»
[^] # Re: Date
Posté par Boa Treize (site web personnel) . Évalué à 3.
# Mercurial, le fils caché de GIT grandit lui aussi
Posté par Edouard Gomez (site web personnel) . Évalué à 9.
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
Posté par ribwund . Évalué à 1.
http://mail.opensolaris.org/pipermail/tools-discuss/2006-Apr(...)
[^] # Re: Mercurial, le fils caché de GIT grandit lui aussi
Posté par Boa Treize (site web personnel) . Évalué à 6.
* 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
Posté par Pinaraf . Évalué à 4.
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
Posté par Edouard Gomez (site web personnel) . É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 !
[^] # Re: Mercurial, le fils caché de GIT grandit lui aussi
Posté par Pinaraf . Évalué à 2.
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
Posté par Vivi (site web personnel) . Évalué à 3.
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.
# Comparaison avec darcs ?
Posté par Xavier Maillard . Évalué à 2.
[^] # Re: Comparaison avec darcs ?
Posté par Lucas Bonnet . Évalué à 4.
[^] # Re: Comparaison avec darcs ?
Posté par Xavier Maillard . Évalué à 1.
[^] # Re: Comparaison avec darcs ?
Posté par alexissoft . Évalué à 5.
A part ça il a des idées vachement bien et c'est assez sympa à utiliser.
# Les RVS décentralisés
Posté par TeXitoi (site web personnel) . Évalué à 1.
Les DRVS se sont pris une grosse envollé lors de l'histoire BK/Git. Un grand nombre de projets était alors dispo avec des fonctionnalités plus ou moins évolué. Il était alors difficile de faire une comparaison à cause de l'évolution rapide et de la multitudes des offres.
Je me demandais donc quelle est l'état des lieux vu que je n'ai trouvé aucune comparaison lisible et efficace entre les DRVS. J'en appelle donc à vos impressions et remarques sur le sujet.
Personnellement, je fais une utilisation basique de bazaar-ng. Les impressions que j'ai sur les différents CRVS sont les suivants :
- Bazaar-ng : soutenu par un gros projet (Ubuntu), avec de bonnes idées et une interface facilement utilisable. Les performances sembles ne pas être au rendez-vous, mais il est prévu qu'il y aie une grosse amélioration rapidement. Il manque encore quelques fonctionnalités comme le taggage de révision et la signature (GPG) intégrée. Il n'y a pas encore de gros projet qui l'utilise.
- Git : C'est le joujou de Linus. très performant sous Linux, mais dès qu'on sort de cet environnement, les performances chutent. Le renomage de fichiers n'est pas vraiment présent. Ce projet est très en vogue à cause de la notoriété de Linus et de Linux. C'est un outils concu, développé et utilisé par/pour le noyau linux.
- Mercurial : Un Git en mieu. Portable, moins bidouille. Même problème sur le renomage de fichier. La communauté est par contre beaucoup moins développé, surement du au fait que mercurial n'a pas la même renommé que Git.
- svk : en complement à svn. Je connais pas du tout
- darcs : semble avoir lancé des idées interessantes et boulversé les mentalités. Il semble avoir des problèmes de performances assez importantes et il n'y a pas de (grosse) communauté autour à cause de son language de programmation, Haksel.
- Les autres (codeville, monotone, tla et surement d'autres) semblent être passé derrière la scène, et risque peut-être de disparaitre.
Merci de faire avancer le débat ;-)
[^] # Re: Les RVS décentralisés
Posté par golum . Évalué à 3.
je connais
rcs : revision control system
vcs : version control sytem
cms: configuration management system
je vais quand même pas devoir tout retagger mes liens sous delicious :)
http://del.icio.us/krazybug/vcs
[^] # Re: Les RVS décentralisés
Posté par TeXitoi (site web personnel) . Évalué à 0.
J'ai mélangé CVS, RVS et VCS.
alors un gros s/ RVS/VCS/g sur mon post du dessus.
[^] # Re: Les RVS décentralisés
Posté par Boa Treize (site web personnel) . Évalué à 3.
Remplacer "Linux" par "Unix", remplacer "chûtent" par "baissent", et ne pas oublier que Windows ne brille pas de manière générale par les performances brutes de son système de fichiers, et que Cygwin n'arrange rien à l'affaire.
Bref, faut pas croire que Git se traîne en dehors d'Unix, mais il est moins rapide c'est vrai. Il y a eu un gros travail sur les performances sous Cygwin, les principaux problèmes ont été éliminés.
Et il n'est pas vraiment nécessaire. C'est CVS qui a obsédé tout le monde avec la gestion du renommage, puisque sous CVS renommer signifie perdre l'historique. Ce problème est énormément minoré quand on gère des changesets. De plus, quand on y regarde de plus près, le renommage de fichiers entiers n'est pas tant fréquent que la copie et le déplacement de portions de code.
Git permet bien sûr de renommer un fichier avec une petite commande toute simple (git-mv). Il n'enregistre pas cette information (l'opération de renommage), mais il permet de détecter automatiquement le renommage et la copie de portions de fichiers, et ça, c'est beaucoup plus intéressant.
Par exemple, entre Git v0.99.1 et v1.0rc4 (purement au hasard), entre autres très nombreuses modifications :
* La moitié de checkout-cache.c s'est retrouvée dans checkout-index.c
* convert-cache.c a été renommé en convert-objects.c
* pull.h a été renommé en fetch.h
* Une bonne partie de ssh-push.c a été copiée dans ssh-upload.c
Ligne de commande :
git-diff-tree -M -C --diff-filter=RC --find-copies-harder v0.99.1 v1.0rc4
Affichage :
(assez moche -- c'est une commande de bas niveau)
C'est sûr que cette fonctionnalité là n'est pas encore très user-friendly, mais elle est là et elle est bien utile.
S'il maintient sa vogue, c'est aussi par sa qualité, et par effet boule de neige : bon développeurs, bon code et bonne ambiance = encore plus de bons développeurs et de bon code.
Pas uniquement. Comme le dit Junio Hamano, le mainteneur de Git, Linux n'est "que" le principal client de Git. Linux est important, mais pas au point de compromettre Git.
Euh... non. Extrêmement similaire (à égalité technique avec Git pour OpenSolaris qui vient de les évaluer, et pourtant Git c'est GNU/Linux, et les développeurs d'OpenSolaris ne sont pas super fans des outils GNU et de Linux) (OpenSolaris a préféré Mercurial pour des raisons de poil brillant et d'un support promis par un développeur-clé de Mercurial).
Ah non. La plupart de Git est bien écrit et bien conçu, tout comme la plupart de Mercurial. Dans les deux, il y a des recoins un peu bidouillés qui peuvent bénéficier d'un petit coup de balai.
Des idées intéressantes, tout à fait, bouleversé les mentalités, faut pas exagérer quand même. Il a par contre été le premier à ma connaissance à montrer à quel point on pouvait faire une interface claire et facile à apprendre (une leçon que Mercurial a bien compris) et à mettre ses données dans un sous-répertoire local (plutôt que dans une arborescence à part centralisée pour tous les projets hébergés sur la machine, genre cvsroot etc.). Git et Mercurial ont repris cette excellente idée.
Ah oui.
Ben en fait il a toute la communauté Haskell, donc ça fait pas mal de gars très intelligents. Mais j'ai pas suivi ces derniers mois.
[^] # Re: Les RVS décentralisés
Posté par agmk . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.