Pourquoi git log peut-il ne pas afficher l'historique d'un fichier déplacé et que puis-je faire à ce sujet?


90

J'ai renommé quelques fichiers en utilisant git mv, utilisé git stash, jeté un coup d'œil rapide à HEAD (sans le changer) puis je l'ai fait git stash poppour récupérer le tout. Mes coups avaient disparu de la liste de commit, donc je les ai refaits avec git rmet le message de commit prétendu que git avait repéré que le changement de nom était un renommage. Alors je n'y ai plus pensé.

Mais maintenant, après la validation, 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% 

(Je l' ai aussi essayé sans -M, -Cet --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'aurais pas envie de faire ce genre de chose tout le temps. (Je prévois avoir un bon nombre de fichiers qui seront déplacés 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 modifiées). Je crois comprendre que git devrait être capable de suivre le fichier dans ce cas, car il en déduit les opérations de changement de nom plutôt que de les stocker explicitement, et les fichiers sont suffisamment similaires pour que je pense qu'il devrait les considérer comme identiques.

Puis-je faire quelque chose pour résoudre ce problème?


Devinez: cela fonctionne-t-il si vous exécutez la commande dans ~ / projects / au lieu de ~ / projects / system / runtime / src?
Douglas

Non, j'obtiens le même résultat. (Semble généralement git assez bien de vous laisser dans un dossier de toute façon ...)

Cela m'a cependant donné une idée et j'ai mis à jour la question avec mes conclusions. Merci pour le commentaire!

J'utilise "tortoiseGit 1.5.8.0" avec "1.7.3.1.msysgit.0" sur mswindows. Lorsque je renomme + validez un fichier dans l'explorateur, je vois dans mon interface graphique "status = Rename". Je ne sais pas assez sur git comment faire cela en ligne de commande pour répondre "comment faire cela" mais tortoiseGit a fait quelque chose pour moi qui a fonctionné comme vous vous attendiez.
k3b

Réponses:



28

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


git log -M --summaryne donne aucune information de changement de nom si vous regardez simplement l'historique d'un fichier donné, c'est-à-dire avec un argument de fichier.
vinc17

17

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

Premièrement, le --summaryjournal de la validation de changement de nom inclut la deleteligne avec l'ancien nom du fichier. Donc, s'il est facile à repérer, vous pouvez trouver son ancien nom et à git logpartir de là.

Si cela fait partie d'un gros commit, et donc un peu plus difficile à repérer - et cette situation était l'un de mes soucis - git blame -Cpeut être utilisé avec le nouveau nom du fichier sur la première révision post-renommée. Il reste vraisemblablement des lignes du fichier d'origine! - donc git devrait trouver leur source et afficher l'ancien nom de fichier (et un hachage de validation pour faire bonne mesure). Vous pouvez ensuite reprendre le sentier avec git log.

Donc, si vous vous intéressez à l'histoire du fichier en tant qu'unité (pour une raison quelconque), 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.


6
Je pense que vous avez besoin de l'option -M pour afficher les noms plutôt que les supprimer / ajouter
Adrian Cornish

1
J'ai juste eu le même problème et j'ai remarqué que votre répertoire de travail fait une différence git log --follow .où le répertoire de travail est le nouvel emplacement ne fonctionne pas, alors que git log --follow path/to/new/dir, exécuté à partir d'un répertoire parent commun de l'ancien et du nouvel emplacement, fonctionne
akraf

1
Le --followparamètre fonctionne, mais vous devez faire:git log --follow -- ./path/to/file
DrumM

Je viens de rencontrer le problème qui git -log filename.css'arrête lors de la validation de mouvement de fichier (le répertoire actuel est défini dans le dossier du fichier). Cependant, la fenêtre d'historique de VS affiche le journal des modifications de fichier complet. Je peux également voir que le fichier a été déplacé avec le bureau Github. Mais git log -10 --follow filename.csaffiche également le journal avant la validation du déplacement.
oleksa

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

Je crois que c'est ce que vous recherchez.


3
La réponse de cinq ans auparavant contient cette information.
dotancohen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.