Comment afficher VRAIMENT les journaux des fichiers renommés avec git?

Je suis relativement nouveau dans git, j'ai utilisé Subversion avant.

J'ai remarqué que la plupart des interfaces graphiques git et des plugins IDE ne semblent pas pouvoir afficher l'historique d'un fichier si le fichier a été renommé. Quand j'utilise

git log --follow

sur la ligne de commande, je peux voir le journal entier à travers les renommés.

Selon Linus Torvalds, le commutateur --follow est un plaisir pour «SVN noob», les utilisateurs sérieux de git ne l'utilisent pas:

--follow est un hack total, destiné à satisfaire les anciens utilisateurs de SVN qui n'ont jamais rien su de choses comme la parentalité ou de jolis graphes de révision de toute façon.

Ce n'est pas totalement fondamental, mais l'implémentation actuelle de "--follow" est vraiment une chose de prétraitement rapide boulonnée sur la logique de marche des révisions, plutôt que d'être vraiment intégrale.

Il a littéralement été conçu comme un plaisir "SVN noob", pas comme une "vraie fonctionnalité git". L'idée était que vous vous échappiez de l'état d'esprit (brisé) de penser que les renommés comptent dans l'ensemble.

Ma question : Comment les utilisateurs hardcore de git parmi vous obtiennent-ils l'historique d'un fichier lorsqu'il a été renommé? Quelle est la «vraie» façon de faire cela?

Je pense que la motivation générale derrière le point de Linus est que - et prenez cela avec une pincée de sel - les utilisateurs de git hardcore ne se soucient jamais de l'histoire d'un "fichier". Vous placez le contenu dans un référentiel git car le contenu dans son ensemble a une histoire significative.

Un changement de nom de fichier est un petit cas particulier de "contenu" se déplaçant entre les chemins. Vous pourriez avoir une fonction qui se déplace entre les fichiers qu'un utilisateur git pourrait traquer avec "pioche" fonctionnellement (par exemple log -S).

D'autres changements de "chemin" incluent la combinaison et le fractionnement de fichiers; git ne se soucie pas vraiment du fichier que vous considérez renommé et de celui que vous considérez comme copié (ou renommé et supprimé), il suit simplement le contenu complet de votre arbre.

git encourage la réflexion «arbre entier» là où autant de systèmes de contrôle de version sont très centrés sur les fichiers. C'est pourquoi git fait plus souvent référence aux "chemins" qu'aux "noms de fichiers".

J'ai exactement le même problème que vous rencontrez. Même si je ne peux pas vous donner de réponse, je pense que vous pouvez lire cet e-mail que Linus a écrit en 2005, il est très pertinent et pourrait vous donner un indice sur la façon de gérer le problème:

… Je prétends que tout SCM qui essaie de suivre les renommés est fondamentalement cassé à moins qu'il ne le fasse pour des raisons internes (c'est-à-dire pour permettre des deltas efficaces), exactement parce que les renommés n'ont pas d'importance. Ils ne vous aident pas et ce ne sont pas ce qui vous intéressait de toute façon .

Ce qui compte, c'est de trouver «d'où cela vient», et l'architecture git le fait très bien en effet - bien mieux que toute autre chose. …

Je l'ai trouvé référencé par cet article de blog, ce qui pourrait également vous être utile pour trouver une solution viable:

Dans le message, Linus a expliqué comment un système de suivi de contenu idéal peut vous permettre de trouver comment un bloc de code a pris la forme actuelle. Vous commenceriez à partir du bloc de code actuel dans un fichier, reviendriez dans l'historique pour trouver le commit qui a changé le fichier. Ensuite, vous inspectez le changement du commit pour voir si le bloc de code qui vous intéresse est modifié par celui-ci, car un commit qui modifie le fichier peut ne pas toucher le bloc de code qui vous intéresse, mais seulement quelques autres parties du fichier.

Lorsque vous constatez qu'avant la validation, le bloc de code n'existait pas dans le fichier, vous inspectez la validation plus en profondeur. Vous constaterez peut-être que c'est l'une des nombreuses situations possibles, notamment:

1. Le commit a vraiment introduit le bloc de code. L'auteur du commit était l'inventeur de cette fonctionnalité intéressante pour laquelle vous recherchiez son origine (ou le coupable qui a introduit le bogue); ou
2. Le bloc de code n'existait pas dans le fichier, mais cinq copies identiques de celui-ci existaient dans différents fichiers, qui ont tous disparu après la validation. L'auteur du commit a refactoré le code dupliqué en introduisant une seule fonction d'assistance; ou
3. (cas particulier) Avant le commit, le fichier qui contient actuellement le bloc de code qui vous intéresse n'existait pas, mais un autre fichier avec un contenu presque identique existait, et le bloc du code qui vous intéresse, ainsi que tous les autres contenus du fichier existaient à l'époque, existaient dans cet autre fichier. Il est parti après la validation. L'auteur du commit a renommé le fichier en lui apportant une modification mineure.

Dans git, l'outil de suivi de contenu ultime de Linus n'existe pas encore de manière entièrement automatisée. Mais la plupart des ingrédients importants sont déjà disponibles.

Veuillez nous tenir au courant de vos progrès à ce sujet.

J'ai remarqué que la plupart des interfaces graphiques git et des plugins IDE ne semblent pas pouvoir afficher l'historique d'un fichier si le fichier a été renommé

Vous serez heureux de savoir que certains outils d'interface utilisateur Git populaires le prennent désormais en charge. Il existe des dizaines d'outils d'interface utilisateur Git disponibles, je ne les énumérerai donc pas tous, mais par exemple:

• SourceTree, lors de la visualisation d'un journal de fichiers, a une case à cocher "Suivre les fichiers renommés" en bas à gauche
• TortoiseGit a une case à cocher «suivre les renommés» dans la fenêtre du journal en bas à gauche.

Plus d'informations sur les outils d'interface utilisateur Git:

• http://git-scm.com/downloads/guis
• https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

Remarque: git 2.9 (juin 2016) améliorera un peu la nature "boguée" de git log --follow:

Voir commit ca4e3ca (30 mars 2016) par SZEDER Gábor ( szeder) .
^{(Fusionné par Junio ​​C Hamano - gitster- in commit 26effb8 , 13 avril 2016)}

diffcore: correction de l'ordre d'itération de fichiers identiques lors de la détection de renommage

Si les deux chemins « dir/A/file» et « dir/B/file» ont un contenu identique et que le répertoire parent est renommé, par exemple « git mv dir other-dir», alors diffcoresignale les noms exacts suivants:

renamed:    dir/B/file -> other-dir/A/file
renamed:    dir/A/file -> other-dir/B/file

(notez l'inversion ici:, B/file -> A/fileet A/file -> B/file)

Bien que techniquement pas faux, cela est déroutant non seulement pour l'utilisateur, mais aussi pour les commandes git qui prennent des décisions basées sur les informations de renommage, par exemple git log --follow other-dir/A/file«suit dir/B/file» après le changement de nom.

Ce comportement est un effet secondaire de commit v2.0.0-rc4 ~ 8 ^ 2 ~ 14 ( diffcore-rename.c: simplifier la recherche de noms exacts, 14/11/2013): la table de hachage stockant les sources renvoie les entrées du même compartiment, c'est-à-dire les sources correspondant à la destination actuelle , dans l'ordre LIFO.
Ainsi, l'itération examine d'abord ' other-dir/A/file' et ' dir/B/file' et, après avoir trouvé un contenu et un nom de base identiques, signale un changement de nom exact.

Sous Linux, j'ai vérifié que SmartGit et GitEye sont capables de suivre les renommés en suivant l'historique d'un fichier particulier. Cependant, contrairement à gitk et GitEye, SmartGit affiche une vue de fichier et une vue de référentiel séparées (qui contient la structure du répertoire mais pas la liste des fichiers contenus dans)