Petit billet d'humeur, adorateurs de git, ça risque de ne pas vous plaire.

Au taff, surement comme un grand nombre d'entre vous, j'utilise git. Et il marche bien la plupart du temps... la plupart du temps.

J'ai fait le tour des système de gestion de contrôle durant ma carrière, ayant travaillé avec subversion, puis bazaar, puis git, puis Mercurial, puis de nouveau git. Dans subversion, mercurial et bazaar, l'historique est sacré. Il n'est pas possible de ré-écrire l'histoire, et on peut toujours savoir qui a fait quoi quand et comment.

La logique des dévelopeurs de git est d'avoir un historique de commits propre en compressant plusieurs petits commits dans un seul gros commit lors du merge en branche principale. Et parlons justement du merge. Git utilise apparemment plusieurs algorithmes de merge, et certains d'entre eux peuvent avoir des problèmes.

J'ai justement eu récemment à faire un merge d'une branche de maintenance vers ma branche de développement. Et quelle ne fut pas ma surprise à terme de constater qu'une fonctionalité ne marchait plus du tout. Un peu d'investigation a révélé que la fonction associé à l'appel n'existait tout simplement plus. Le code a tout bonnement disparu. Pensant à une erreur de merge lors d'un conflit, j'ai donc recherché le code manquant dans l'historique de git; qui fut effectivement trouvé. Seulement voilà, git trouve bien le moment où le code a été ajouté, mais selon lui, il n'a jamais été enlevé!

L'erreur est surement mienne, certains merges étant ardus. Mais pourquoi diable git n'a aucune notion du fait que le code ait été enlevé du fichier à un certain point? C'est la seconde fois que cette mésaventure m'arrive, j'avais vu un rapport de bug à ce sujet il y a quelques mois, j'espère que c'est pris au sérieux par les dévelopeurs.

Original post of Etenil.Votez pour ce billet sur Planet Libre.