Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger.
Attention astuce : on paye pas plus cher si on fait un rebase -i dès qu'on a repéré qu'on a oublié un truc dans l'antépénultième commit.
Ensuite pour l'histoire que le réordonnancement est plus simple qu'avec un rebase ; il fait comment quand t'as vraiment des changements non inversibles, stgit, il devine ton intention ? Cool je vais pouvoir arrêter de coder si l'outil le fait à ma place !
Par exemple avoir toujours un patch final contenant une conf particulière. Lorsque je développe je l'applique, lorsque je commit/push, il ne l'est pas. Peut-être y a-t-il d'autres moyens, mais celui-ci est vraiment pratique.
C'est le seul truc où je veux bien envisager que c'est mieux. A priori je ferais ça avec des stashs, qui n'est pas le truc le plus souple de git.
[^] # Re: Je profite de ce troll
Posté par Sufflope (site web personnel) . En réponse au journal Microsoft passe à git. Évalué à 2.
Attention astuce : on paye pas plus cher si on fait un rebase -i dès qu'on a repéré qu'on a oublié un truc dans l'antépénultième commit.
Ensuite pour l'histoire que le réordonnancement est plus simple qu'avec un rebase ; il fait comment quand t'as vraiment des changements non inversibles, stgit, il devine ton intention ? Cool je vais pouvoir arrêter de coder si l'outil le fait à ma place !
C'est le seul truc où je veux bien envisager que c'est mieux. A priori je ferais ça avec des stashs, qui n'est pas le truc le plus souple de git.