Plus tard je merge X dans master: il y a un conflit car X est appliqué deux fois, git ne réalise pas que c'est "le même commit".
Dans 90% des cas, git va réaliser que c'est le même commit (cf. git-patch-id(1)). Dans 9% des cas où il bloquera, on se rendra compte que le merge n'est pas si « évident » que ça en pratique, et peut-être qu'il va même nécessiter de le re-travailler. Et dans 1% des cas, peut-être que oui, il aurait pu s'en rendre compte et le faire tout seul mais n'y arrivera pas. Et pour augmenter encore la possibilité de résolution, utiliser git-rerere(1).
Bref, pour 99% des cas qui concernent ce problème précis, git va être le meilleur en pratique. Et vu que ce problème n'est pas rencontré si souvent, dans 99,999% des cas d'utilisation de git en général, il sera supérieur. À moins que tu arrives au même niveau sur tout le reste de git : fiabilité, communauté, évolution, rapidité, etc.
Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique. Oui, c'est mieux quand un outil semble « parfait » jusqu'au bout, mais pour ce problème en particulier je pense qu'on n'arrivera jamais à une jolie théorie des patchs qui n'ait pas des perfs de merdes et une complexité ahurissante, tout ça pour un gain très très minime.
Bon courage pour l'expérimentation en tous cas, ça doit être marrant à coder !
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 5.
Dans 90% des cas, git va réaliser que c'est le même commit (cf. git-patch-id(1)). Dans 9% des cas où il bloquera, on se rendra compte que le merge n'est pas si « évident » que ça en pratique, et peut-être qu'il va même nécessiter de le re-travailler. Et dans 1% des cas, peut-être que oui, il aurait pu s'en rendre compte et le faire tout seul mais n'y arrivera pas. Et pour augmenter encore la possibilité de résolution, utiliser git-rerere(1).
Bref, pour 99% des cas qui concernent ce problème précis, git va être le meilleur en pratique. Et vu que ce problème n'est pas rencontré si souvent, dans 99,999% des cas d'utilisation de git en général, il sera supérieur. À moins que tu arrives au même niveau sur tout le reste de git : fiabilité, communauté, évolution, rapidité, etc.
Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique. Oui, c'est mieux quand un outil semble « parfait » jusqu'au bout, mais pour ce problème en particulier je pense qu'on n'arrivera jamais à une jolie théorie des patchs qui n'ait pas des perfs de merdes et une complexité ahurissante, tout ça pour un gain très très minime.
Bon courage pour l'expérimentation en tous cas, ça doit être marrant à coder !