Nous avons un projet d'environ 500 000 lignes de code, géré avec git, dont une grande partie date de plusieurs années. Nous sommes sur le point d'effectuer une série de modifications pour mettre l'ancien code en conformité avec les normes et les meilleures pratiques actuelles de la communauté des développeurs, en ce qui concerne les conventions de dénomination, la gestion des exceptions, l'indentation, etc.
On peut considérer qu'il s'agit de quelque chose qui se situe entre l'impression et le remaniement mécanique de bas niveau.
Ce processus est susceptible de toucher presque chaque ligne de code de la base de code (~85%), et certaines lignes feront l'objet de jusqu'à cinq modifications. Toutes les modifications sont destinées à être sémantiquement neutres.
- Existe-t-il un moyen de rendre les changements transparents pour le git blame, etc., de sorte que lorsque l'on regarde le code dans un mois, on voit le commit dans lequel la logique a été introduite, et non celui dans lequel l'indentation ou la capitalisation a été modifiée ?
- Quelle est la meilleure façon de tirer des fusions de fourches qui n'ont pas subi ce processus ? Mon plan actuel serait qu'un script clone le repo fork, applique le processus automatisé à celui-ci et à sa base, les diffère, puis applique la diff. Mais j'aimerais avoir une réponse plus propre.
- Y a-t-il d'autres problèmes de ce type que je ne vois pas, et si oui, que peut-on faire pour les atténuer ? Je pense que git bisect, etc. devrait être correct, git log, etc. traversant le grand fossé sera ennuyeux à moins que vous ne soyez prudent, et git diff sera sans espoir, mais je ne suis pas convaincu que je ne néglige pas un autre point sensible.
