Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.
Si l'on reprend ton exemple et que -comme dans la vraie vie où l'on a décidé de ne pas livrer un changeset pour une release donnée, car la feature n'était pas prête- l'on l'intègre par la suite, on peut avoir quelques surprises :
Quel est le contributeur de base ici ? A3 ? ABC ?
Il y a quelques chances que le futur merge considère que la suppression des commits A(1,2,3)= BC soit retenue dans le merge automatique et qu'on ne retrouve pas ces commits que l'on voudrait intégrer.
Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux. J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.
En attendant, la bonne pratique, que tu "insinues" alambiquée est de ne pas intégrer les features non complètes et plutôt de merger depuis (ou rebaser sur) le trunk régulièrement pour se tenir à jour. On appelle ça: le feature branching.
Au pire, on constate les dégâts rapidment (vive la CI) et l'on reconstruit une branche bien propre à base de rebase interactifs.
Dans "la vraie vie", on aurait plutôt quelque chose de ce genre:
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.
Si l'on reprend ton exemple et que -comme dans la vraie vie où l'on a décidé de ne pas livrer un changeset pour une release donnée, car la feature n'était pas prête- l'on l'intègre par la suite, on peut avoir quelques surprises :
Quel est le contributeur de base ici ? A3 ? ABC ?
Il y a quelques chances que le futur merge considère que la suppression des commits A(1,2,3)= BC soit retenue dans le merge automatique et qu'on ne retrouve pas ces commits que l'on voudrait intégrer.
Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux. J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.
En attendant, la bonne pratique, que tu "insinues" alambiquée est de ne pas intégrer les features non complètes et plutôt de merger depuis (ou rebaser sur) le trunk régulièrement pour se tenir à jour. On appelle ça: le feature branching.
Au pire, on constate les dégâts rapidment (vive la CI) et l'on reconstruit une branche bien propre à base de rebase interactifs.
Dans "la vraie vie", on aurait plutôt quelque chose de ce genre:
Bref, "dans la vraie vie" ton cas n'existe quasiment JA-MAIS