URL: https://linuxfr.org/users/minimock/journaux/git-a-fete-ses-10-ans-hier Title: Git a fêté ses 10 ans hier ... Authors: El Titi Date: 2015年04月08日T15:32:26+02:00 License: CC By-SA Tags: git, mercurial et fossil Score: 56 ... et même pas une moule pour relayer cette petite interview de son papa: http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds Les 10 ans de Git pour changer un peu des bougies, c'est aussi l'occasion de se pencher sur la mémoire de tous ses challengers qui ont rejoint le panthéon des logiciels. Paix ait leur âme. C'est peut-être aussi l'occasion de ressusciter quelques trolls endormis en mémoire du bon vieux temps, car bon, en lisant cette interview moi j'ai plutôt le souvenir d'un bon vieux syndrome NIH pour justifier sa naissance... Alors remontons un peu le temps: Souvenez-vous ! La guerre des DVCS était déclarée. Ce bon vieux Subversion, incapable de rejouer un merge sans ré-appliquer tous les commits déjà traités enterrait enfin ce vénérable CVS. Le fameux "merge-tracking" nous est venu plus tard avec la 1.5 en introduisant une usine à gaz nommée ["mergeinfo"](https://www.open.collab.net/community/subversion/articles/merge-info.html). Mais comme c'était l'avènement des méthodes agiles avec le fameux "trunk dev", on nous chantait les louanges de l'intégration continue en vouant aux gémonies les ["Feature Branches"](http://martinfowler.com/bliki/FeatureBranch.html). Vous ne pouvez pas utiliser les branches avec SVN ? On va vous expliquer comment vous en passer (Coluche si tu m'entends) à coup de [Feature Toggling](http://martinfowler.com/bliki/FeatureToggle.html) ou de [Branch by abstration](http://martinfowler.com/bliki/BranchByAbstraction.html). Ou comment faire passer un mauvais design pour une killer feature. La force des DVCS pour plier tout ça ? (outre le travail en local et les temps d'accès): le fameux [DAG](http://en.wikipedia.org/wiki/Directed_acyclic_graph) des commits. A cette époque, un petit gars nommé Tom Lord nous avait pondu un hack du tonnerre en Perl et parfaitement incompréhensible qui s’appelait [Gnu Arch](http://www.gnu.org/software/gnu-arch/). [Monotone](http://www.monotone.ca/), un autre soft plutôt bien conçu a émergé en C++ avec ce concepts de multiples "heads" associées à une même branche, qui a sans doute inspiré ce vénérable Mercurial. [Darcs](http://darcs.net/) écrit en Haskell, avait pris une direction différente. Son auteur, David Roundy nous avait pondu sa brillante [théorie des patches](http://darcs.net/Theory). Génialisssime, même si je n'ai jamais vraiment bien compris à quoi ça pouvait servir. [Codeville](http://web.archive.org/web/20060113052047/http://codeville.org/) écrit en python, auquel un certain [Bram Cohen](http://en.wikipedia.org/wiki/Bram_Cohen) qui s'y connait un peu en P2P a participé, nous apportait son algorithme de merge "révolutionnaire". Visiblement ca ne satisfaisait pas ce cher Linus. Pas que [Mercurial](http://mercurial.selenic.com/) ne se soit lancé pour répondre au besoin. Pas que [Bazar](http://bazaar.canonical.com/en/) propulsé par Canonical et son controversé mécène ne se soit lancé dans l'affaire en proposant une forge associée. Il avait le mérite de supporter un mode hybride avec lequel on pouvait choisir entre le mode centralisé (commit dans la même branche avec verrou pessimiste possible) et le mode décentralisé (ceux qui ont connu Clearcase multisite saisiront mieux l'analogie). Mais voilà, il était lent, Canonical représentaient les méchants de l'époque et le temps qu'ils améliorent ses perfs, que Launchpad soit libéré, c'était bien trop tard. Ce que voulait Linus en fait, c'était Bitkeeper en libre. On a vu aussi émerger des chimères assez étranges comme [svk](http://www.perl.com/pub/2004/03/03/svk.html) un hack de SVN en perl qui essayait de le rendre distribué (l'apparentant à Bazaar pour le coup). Il y a aussi eu ceux arrivés après la bataille: Ils partaient d'un bon sentiment: décentraliser la gestion des tickets en même temps que celle du code. Nous avons eu [Fossil](http://fossil-scm.org/index.html/doc/trunk/www/index.wiki) et [Veracity](http://veracity-scm.com/) écrit en C dont l'auteur Eric sink proposait auparavant un outil payant sous Windows (Vault). L'idée est bonne mais maintenant Git s'est imposé et depuis on l'a castré en le recentralisant avec les tickets dans des forges bien propriétaires qui proposent de gérer ses pull request sur le serveur comme GitHub, Stash ou Bitbucket (Le Stash online). On ne marcherait pas un peu sur la tête ? Git les a donc tous balayé. Sa puissance, ses qualités et son architecture y sont pour quelque chose; l'aura de son créateur bien plus selon moi. Reste un petit goût amer, comment un produit si efficace peut-il avoir une interface en ligne de commande aussi inconsistante, imprévisible sans qu'on l'ait remis à plat ? - Vous aussi, ça vous défrise de faire git checkout sur un nom de branche pour l'activer ? - Vous aussi, vous vous demandez pourquoi il faut faire un git checkout -b pour créer une branche et un git branch -d pour la supprimer ? - Vous aussi, vous oubliez toujours qu'il faut fait un git reset HEAD pour vider l'index ? - Vous aussi vous avez bookmarké la moitié de Stack Overflow et vous collectionnez les cheat cheet sur Git ? ... vous n'êtes plus seul: http://www.saintsjd.com/2012/01/a-better-ui-for-git/ Bon Anniversaire Git ! En attendant la naissance de ton petit frère laissons la parole à ton papa.> **Does Git last forever, or do you foresee another revision control system in another 10 years? Will you be the one to write it?** >Torvalds: I'm not going to be the one writing it, no. And maybe we'll see something new in ten years, but I guarantee that it will be pretty "git-like." It's not like git got everything right, but it got all the really basic issues right in a way that no other SCM had ever done before.>No false modesty ;)

AltStyle によって変換されたページ (->オリジナル) /