J'aimerais vraiment que on arrête la notion de diff et que on passe à des changeset sémantiques en gardant le diff en dernier recours.
Quand je déplace un bout de code, renomme un ensemble de fonctions, ajoute un test autour d'un bloc de code et indente celui-ci, j'aimerais vraiment que les merges futurs continuent d'avoir cette information pour merger mon code.
Typiquement, après un merge entre une branche refactorée (où on a changé le nom de la fonction haha en hihi) et une autre branche qui a ajouté un appel à cette fonction, le merge peut bien se passer, en laissant tout fois un code invalide car il reste l'appel qui n'a pas été renommé. (d'ailleurs, vous reglez cela dans le merge ou dans un commit suivant ?)
Je ne sais pas à quel point il serait possible de faire des commit qui décrivent non pas le changement, mais la recette du changement (Cela pourrait bêtement être un script).
[^] # Re: c'est une question de philosophie
Posté par Guillaum (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Un jour j'utiliserais Darcs rien que pour cela.
J'aimerais vraiment que on arrête la notion de diff et que on passe à des changeset sémantiques en gardant le diff en dernier recours.
Quand je déplace un bout de code, renomme un ensemble de fonctions, ajoute un test autour d'un bloc de code et indente celui-ci, j'aimerais vraiment que les merges futurs continuent d'avoir cette information pour merger mon code.
Typiquement, après un merge entre une branche refactorée (où on a changé le nom de la fonction haha en hihi) et une autre branche qui a ajouté un appel à cette fonction, le merge peut bien se passer, en laissant tout fois un code invalide car il reste l'appel qui n'a pas été renommé. (d'ailleurs, vous reglez cela dans le merge ou dans un commit suivant ?)
Je ne sais pas à quel point il serait possible de faire des commit qui décrivent non pas le changement, mais la recette du changement (Cela pourrait bêtement être un script).