C'est la même justification et solution que bzr, et ca explique aussi pourquoi tout le monde trouve bzr improductif (bon y'a pleins d'autres raisons aussi).
Tant que c'est local, je veux pouvoir réordonner, fusionner, modifier, supprimer mes commits. Ca n'a aucun sens de:
Se tapper des historiques pourris type: "Commit 1", "Oups ajout du fichier manquant", "Commit 2", "Oups correction d'un bug introduit par commit 1". Quand toutes ces étapes ont été attrapées avant que le code soit publique.
Perde le découpage des commits (si tu sors le diff de ta branch pour mettre à plat comme recommande certains SCM. Sisi ! ).
Ton code avant de passer publique, il passe en code review. Avoir un historique propre ca permet de faire des codes review simples. Et pouvoir modifier ses commits ca permet d'updater facilement ses patchs suite à la code review.
[^] # Re: Pas de révision d'historique
Posté par ckyl . En réponse au journal Chiselapp ferme ses portes. Évalué à 2.
C'est la même justification et solution que bzr, et ca explique aussi pourquoi tout le monde trouve bzr improductif (bon y'a pleins d'autres raisons aussi).
Tant que c'est local, je veux pouvoir réordonner, fusionner, modifier, supprimer mes commits. Ca n'a aucun sens de:
Se tapper des historiques pourris type: "Commit 1", "Oups ajout du fichier manquant", "Commit 2", "Oups correction d'un bug introduit par commit 1". Quand toutes ces étapes ont été attrapées avant que le code soit publique.
Perde le découpage des commits (si tu sors le diff de ta branch pour mettre à plat comme recommande certains SCM. Sisi ! ).
Ton code avant de passer publique, il passe en code review. Avoir un historique propre ca permet de faire des codes review simples. Et pouvoir modifier ses commits ca permet d'updater facilement ses patchs suite à la code review.