C'est bien, tu as justement pointé une grosse différence entre les deux solutions :
au moment de reverser l'évolution
C'est donc deux façon de faire très différentes. Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger. Dans le cas que j'exposais, on se soucie d'avoir un historique propre et cohérent pendant le développement. Et ça change tout.
Et en plus, côté facilité et confort d'utilisation on est quand même vraiment très loin. Stgit est beaucoup plus agréable à utiliser que rebase -i. Dans les trucs utiles, les piles de patches ça permet aussi d'avoir des patches non appliqués. 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.
[^] # Re: Je profite de ce troll
Posté par CrEv (site web personnel) . En réponse au journal Microsoft passe à git. Évalué à 3.
C'est bien, tu as justement pointé une grosse différence entre les deux solutions :
C'est donc deux façon de faire très différentes. Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger. Dans le cas que j'exposais, on se soucie d'avoir un historique propre et cohérent pendant le développement. Et ça change tout.
Et en plus, côté facilité et confort d'utilisation on est quand même vraiment très loin. Stgit est beaucoup plus agréable à utiliser que rebase -i. Dans les trucs utiles, les piles de patches ça permet aussi d'avoir des patches non appliqués. 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.