Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
Projet Skara : OpenJDK abandonne Mercurial au profit de Git

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.

7 commentaires
Avatar de stratic Abonné
Avatar de straticstratic- 02/10/20 à 11:34:56

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.

Avatar de alban_auzeill INpactien
Avatar de alban_auzeillalban_auzeill- 02/10/20 à 13:03:30

@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!

Avatar de Baradhur INpactien
Avatar de BaradhurBaradhur- 02/10/20 à 14:12:41

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!

Avatar de chasis.fan Abonné
Avatar de chasis.fanchasis.fan- 02/10/20 à 17:36:01

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

Avatar de Vser Abonné
Avatar de VserVser- 02/10/20 à 19:50:55
Baradhur
git gc --aggressive

? :langue:

Édité par Vser le 02/10/2020 à 19:52
Avatar de marba Abonné
Avatar de marbamarba- 03/10/20 à 00:39:27
stratic

La popularité de git est entièrement mérité.

Avatar de Exagone313 Abonné
Avatar de Exagone313Exagone313- 03/10/20 à 13:06:35

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.

Édité par Exagone313 le 03/10/2020 à 13:09
Il n'est plus possible de commenter cette actualité.