L'idée n'est pas nouvelle puisque le fait de changer de gestionnaire de versions a été initiée l'année dernière. Cela a néanmoins demandé un gros travail, notamment d'adaptation (des empreintes, outils), pour préserver l'historique et les tags.
L'équipe avait évoqué sa volonté de réduire la taille des métadonnées, mais aussi de profiter de l'écosystème né autour de Git ces dernières années comme motivations principales. La plateforme d'hébergement retenue est GitHub.
Le service, racheté par Microsoft il y a quelques années maintenant, se félicite bien entendu de cette initiative, et revient dans un billet de blog sur le projet et les méthodes utilisées.
Commentaires (7)
#1
C’est incroyable comment poussés par la popularité, ce ne sont pas nécessairement les meilleurs outils qui subsistent. Je comprends les raisons du changement. Elles ne sont pas liées à la solution, mais à l’écosystème qui gravite autour. Personnellement, pour des raisons similaires, je suis aussi amené à migrer (à contre cœur) des référentiels Mercurial vers Git. Alors que, Mercurial est pourtant autrement mieux pensé et plus robuste que Git. Son seul défaut étant de ne pas être populaire. Le plus gros problème de Git est de permettre, de base, la ré-écriture de l’historique. Ça conduit inévitablement, à la première étourderie, à des situations ubuesques où il devient difficile d’échanger entre les différents acteurs d’un projet. La même chose est juste impossible sous Mercurial.
#1.1
La popularité de git est entièrement mérité.
#2
@stratic Même si Git permet de ré-écrire l’historique, GitHub fournit (avec l’offre Pro) une protection qui peut l’interdire (par branche). En local les nouveaux commits peuvent être ré-écrit pour être raffinés avant d’être poussés, mais pas touche aux anciens commits!
#3
Non git ne permet pas de reecrire l’historique, rien n’est jamais perdu et tout commit peut etre retrouve. Il est juste plus facile de pouvoir rebifurquer a partir d’une point precis.
Pour avoir bosser avec git snv et mercurial, git est pour moi le meilleur en termes de compromis entre flexibilite et stabilite. Je suis content d’y etre et d’y reste!
#3.1
?
#4
C’est bien pratique de pouvoir réécrire l’historique pour effacer des mots de passe / clé api / secrets divers et variés comités par erreur.
Ou autre exemple que je trouve beaucoup dans ma boite : d’anciens projets datant d’une époque où les gestionnaires de dépendances n’était pas utilisés, résultats, les bibliothèques java (fichiers jar) toutes stocké dans SVN, entre temps migré sur git par des équipes dédiées ne faisant pas dans le détail.
Git est pas trop fait pour stocker des tonnes de gros blob binaires comme ces bibliothèques java, ca plombe un peu les perf en fonction du volume et effacer ces fichiers ne résout rien : ils restent dans l’historique mais grace à la réécriture d’historique possible et à certains outil automatisant cela (git filter branch en natif, git BFG ou les plus récents git filter-repo / GitRewrite
Dans ce genre de cas tu push force pour réécrire l’historique sur le repo distant, c’est le but. Mais dans un cas plus de tous les jours, tu push ta branche, te rend compte de 2⁄3 conneries et pour faire plus propre tu rebase interactive / amend, tant pis pour la réécriture de l’historique sur le repo distant, tant que c’est sa propre branche ne concernant personne d’autre et qu’il n’y a pas encore de grosse review engagée risquant d’être désynchronisée
#5
Git ne possède pas les fonctionnalités de hg-evolve, c’est une extension très pratique de Mercurial pour réécrire l’historique en coopération (ça permet par exemple de transmettre au serveur la liste des commits obsolètes et un lien vers leur réécriture). De plus, Mercurial possède des interfaces ncurses plus pratiques que Git. hg-git permet de travailler avec Mercurial sur un référentiel Git.
Mercurial est de moins en moins supporté, BitBucket a arrêté son support cet été. Comme forge existante, Heptapod est un fork de GitLab qui avance bien.