C'est surtout le mainteneur qui déteste les commits de merge, et ceci dit, je suis assez d'accord dans le cas de GIMP.
En gros, le but principal d'un commit de merge, c'est essentiellement "garder l'historique". Un commit doit garder son hash à jamais pour pouvoir être toujours retrouvable, histoire de ne jamais casser des liens ou rendre des discussions sur un changement particulier incompréhensible (car tu ne peux plus retrouver le commit discuté si le hash a changé).
Ça a beaucoup de sens sur de très gros projets avec énormément de contributeurs, etc. et surtout avec des branches de longue haleine. Par exemple si la branche principale est celle du mainteneur et chaque "lieutenant" (ou sous/co-mainteneur) a des branches (voire un remote) à lui, etc. Dans un tel contexte, on veut faire en sorte que toutes ces branches publiques à vie indéterminée gardent leur historique pour garder toute la cohérence.
Dans un projet comme GIMP avec 3 ou 4 développeurs permanents (et pas mal de gens externes qui font juste un patch par ci par là), qui bossent directement sur la branche master, ça a beaucoup moins d'importance. Quand on fait des branches de fonctionnalités, en général, on peut souvent juste les supprimer après coup, histoire de faire un peu le ménage. Une fois mergées, elles ne sont jamais retouchées. Et de toutes façons, même quand elles sont encore actives, nos branches ont en général quasi qu'un seul développeur (sauf à la toute fin, quand une revue est nécessaire et que quelques corrections sont faites éventuellement).
Dans ce cas, le seul intérêt du commit de merge est quasi complètement annihilé. Par contre ses défauts sont toujours là, et assez énormes: les commits de merge rendent un historique de commits vraiment illisibles. Je sais pas si tu as vraiment vu des arbres de commits (en vue non-linéaire) de gros dépôts, et notamment lorsqu'ils ont mergés des branches qui contenaient des dizaines de commits sur plusieurs mois. C'est juste une source de mal de tête.
Et je parle même pas de la vue linéaire (celle par défaut d'un git log) qui est rendue totalement inutile dans ce cas.
Dans notre cas hypothétique d'un gros projet dont la branche principale est quasi jamais développée directement et ne sert qu'à merger des branches publiques (qui elles accueillent du développement), c'est encore gérable. Mais un projet avec du développement quotidien et des commits de merge, c'est vraiment assez horrible.
Personnellement je ne serais pas contre des commits de merge sur certaines fonctionnalités de longue haleine qui ont nécessité des semaines ou mois sur une branche à part. Mais le monstre créé par les github/gitlab qui te font des commits de merge de partout pour un rien (genre: un patch de typo? Hop commit de merge!), c'est une aberration et surtout un abus complet du système et de la logique de git.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Commit de fusion ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.2. Évalué à 10.
C'est surtout le mainteneur qui déteste les commits de merge, et ceci dit, je suis assez d'accord dans le cas de GIMP.
En gros, le but principal d'un commit de merge, c'est essentiellement "garder l'historique". Un commit doit garder son hash à jamais pour pouvoir être toujours retrouvable, histoire de ne jamais casser des liens ou rendre des discussions sur un changement particulier incompréhensible (car tu ne peux plus retrouver le commit discuté si le hash a changé).
Ça a beaucoup de sens sur de très gros projets avec énormément de contributeurs, etc. et surtout avec des branches de longue haleine. Par exemple si la branche principale est celle du mainteneur et chaque "lieutenant" (ou sous/co-mainteneur) a des branches (voire un remote) à lui, etc. Dans un tel contexte, on veut faire en sorte que toutes ces branches publiques à vie indéterminée gardent leur historique pour garder toute la cohérence.
Dans un projet comme GIMP avec 3 ou 4 développeurs permanents (et pas mal de gens externes qui font juste un patch par ci par là), qui bossent directement sur la branche
master, ça a beaucoup moins d'importance. Quand on fait des branches de fonctionnalités, en général, on peut souvent juste les supprimer après coup, histoire de faire un peu le ménage. Une fois mergées, elles ne sont jamais retouchées. Et de toutes façons, même quand elles sont encore actives, nos branches ont en général quasi qu'un seul développeur (sauf à la toute fin, quand une revue est nécessaire et que quelques corrections sont faites éventuellement).Dans ce cas, le seul intérêt du commit de merge est quasi complètement annihilé. Par contre ses défauts sont toujours là, et assez énormes: les commits de merge rendent un historique de commits vraiment illisibles. Je sais pas si tu as vraiment vu des arbres de commits (en vue non-linéaire) de gros dépôts, et notamment lorsqu'ils ont mergés des branches qui contenaient des dizaines de commits sur plusieurs mois. C'est juste une source de mal de tête.
Et je parle même pas de la vue linéaire (celle par défaut d'un
git log) qui est rendue totalement inutile dans ce cas.Dans notre cas hypothétique d'un gros projet dont la branche principale est quasi jamais développée directement et ne sert qu'à merger des branches publiques (qui elles accueillent du développement), c'est encore gérable. Mais un projet avec du développement quotidien et des commits de merge, c'est vraiment assez horrible.
Personnellement je ne serais pas contre des commits de merge sur certaines fonctionnalités de longue haleine qui ont nécessité des semaines ou mois sur une branche à part. Mais le monstre créé par les github/gitlab qui te font des commits de merge de partout pour un rien (genre: un patch de typo? Hop commit de merge!), c'est une aberration et surtout un abus complet du système et de la logique de git.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]