Pourquoi git log n'affiche-t-il pas l'historique d'un fichier déplacé, et que puis-je faire à ce sujet ?

Question

J'ai renommé un certain nombre de fichiers en utilisant git mv utilisé git stash J'ai jeté un coup d'œil rapide à HEAD (sans le modifier), puis j'ai fait ce qui suit git stash pop pour récupérer le tout. Mes mouvements avaient disparu de la liste de commit, donc je les ai refaits avec git rm et le message de commit prétendait que git avait repéré que le renommage était un renommage. Je n'y ai donc plus pensé.

Mais maintenant, post-commit, je ne peux pas accéder à l'historique des fichiers déplacés ! Voici ce que dit git à propos du commit en question :

~/projects% git log --summary
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime

 delete mode 100644 test/R_DebugUI_iOS.h
 delete mode 100644 test/R_DebugUI_iOS.m
 create mode 100644 system/runtime/src/R_DebugUI_iOS.h
 create mode 100644 system/runtime/src/R_DebugUI_iOS.m

 <<snip older commits>>
 ~/projects%

J'essaie maintenant d'obtenir l'historique de l'un de ces fichiers déplacés, afin de pouvoir consulter une ancienne version, mais je n'obtiens rien de très utile :

~/projects/system/runtime/src% git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime
~/projects/system/runtime/src% 

(J'ai aussi essayé sans -M , -C y --find-copies-harder mais en vain).

Je peux obtenir son historique sous son ancien nom, qui s'arrête au moment où il a été supprimé de son ancien emplacement :

~/projects% git log --summary --follow --find-copies-harder -M -C -- test/R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date:   Wed Dec 8 22:37:54 2010 +0000

    Moved R_DebugUI into runtime

 delete mode 100644 test/R_DebugUI_iOS.m

commit 32a22d53c27e260714f759ecb3d3864e38b2e87f
Author: brone
Date:   Tue Dec 7 23:52:51 2010 +0000

    Can set debug UI's alpha.

<<snip older commits>>
~/projects%

Je ne suis donc pas complètement coincé cette fois, mais je n'aimerais pas avoir à faire ce genre de choses tout le temps. (Je prévois d'avoir un bon nombre de fichiers qui vont bouger au moins une fois dans leur vie).

Est-ce que je fais quelque chose de mal ? L'ancienne copie du fichier et la nouvelle copie sont identiques à 98,8 % (2 lignes sur 166 ont changé). Si je comprends bien, git devrait être capable de suivre le fichier dans ce cas, car il déduit les opérations de renommage plutôt que de les stocker explicitement, et les fichiers sont suffisamment similaires pour qu'il les considère comme identiques.

Y a-t-il quelque chose que je puisse faire pour réparer ça ?

Answer 1

Veuillez essayer avec git log --follow sur votre dossier. J'apprends ici Est-il possible de déplacer/renommer des fichiers dans git et de conserver leur historique ?

Answer 2

Eh bien, je vois mes renommages avec git log -M --summary ..

Answer 3

Répondre à ma propre question, puisque j'ai réussi à apaiser mes inquiétudes, même si je n'ai pas résolu exactement mon problème. ( git log --follow ne fonctionne toujours pas pour moi, cependant).

Tout d'abord, le --summary Le journal de l'opération de renommage comprend le delete avec l'ancien nom du fichier. Ainsi, s'il est facile à repérer, vous pouvez trouver son ancien nom et git log à partir de là.

S'il s'agit d'une partie d'un engagement important, et donc un peu plus difficile à repérer -- et cette situation était l'une de mes préoccupations -- git blame -C peut être utilisé avec le nouveau nom du fichier lors de la première révision post-renommage. Il reste vraisemblablement des lignes du fichier original ! -- donc git devrait trouver leur source, et montrer l'ancien nom du fichier (et un hash de commit pour faire bonne mesure). Vous pouvez alors reprendre la piste avec git log .

Ainsi, si vous vous intéressez à l'histoire du dossier en tant qu'unité (pour quelque raison que ce soit), il semble que cela puisse être fait de manière relativement simple. Bien que j'ai l'impression que git préférerait que vous l'utilisiez correctement.

Answer 4

git log --follow ./path/to/file

Je crois que c'est ce que vous recherchez.