En effet, je ne dispute pas le fait que de toute façon il faut toujours regarder le résultat d'un merge. Mais je ne pense que pas qu'il faut voir pijul comme un projet qui veut remplacer git. L'idée c'est plutôt d'expérimenter avec un modèle différent.
D'ailleurs je ne dirais pas qu'il y a pas que c'est futile. En problème typique en git qui n'existe pas en pijul et darcs: je fork master dans une branche X. Je fais plein de commits, de son côté master diverge. Puis je cherry-pick un commit de master très important dans X. 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". Je recommande de lire les deux articles suivants qui expliquent bien les différences, cela ne concerne pas que les merge: merging et merging and pjiul (notamment "Case study 2: parallel development" pour l'exemple ci-dessus).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pamaury . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
En effet, je ne dispute pas le fait que de toute façon il faut toujours regarder le résultat d'un merge. Mais je ne pense que pas qu'il faut voir pijul comme un projet qui veut remplacer git. L'idée c'est plutôt d'expérimenter avec un modèle différent.
D'ailleurs je ne dirais pas qu'il y a pas que c'est futile. En problème typique en git qui n'existe pas en pijul et darcs: je fork master dans une branche X. Je fais plein de commits, de son côté master diverge. Puis je cherry-pick un commit de master très important dans X. 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". Je recommande de lire les deux articles suivants qui expliquent bien les différences, cela ne concerne pas que les merge:
merging et merging and pjiul (notamment "Case study 2: parallel development" pour l'exemple ci-dessus).