Pourquoi "git log -- foo" ne fonctionne-t-il pas pour le fichier supprimé foo?
Mon référentiel a subi des modifications telles que:
- ... des engagements non liés ...
- Validez le nouveau fichier
fooavec 100 lignes de contenu - ... des validations intermédiaires, dont certaines touchent
foo... - Insérez le contenu de
fooen haut d'un fichier existantbaretgit rm foodans le même commit - ... d'autres engagements non liés ...
Maintenant, je veux voir le journal du fichier supprimé foo. Tout ce que j'ai lu, y compris sur SO, dit que je devrais pouvoir git log -- foo, mais cette commande ne produit aucune sortie.
Si je trouve le commit qui inclut la suppression de foo je peux git log 1234abcd -- foo et voir son journal, donc je pense que mon chemin vers foo n'est pas le problème. Notez également que git merge-base HEAD 1234abcd les sorties 1234abcd[...], donc je pense que cela devrait prouver que le commit est accessible depuis HEAD. Notez qu'il n'y a pas de fichier foo dans mon arbre de travail (évident, car il a été supprimé). Utilisation de Git 1.7.1.1 sur OS X.
Pourquoi git log -- foo travailler pour moi et comment y remédier? Merci!
Vous souhaitez utiliser le --follow option sur git log, décrit dans la page de manuel comme suit:
Continue listing the history of a file beyond renames.
En effet, non seulement cela vous permet de voir l'historique d'un fichier renommé, mais cela vous permet également d'afficher l'historique d'un fichier qui n'est plus dans l'arborescence de travail. La commande que vous devez utiliser devrait donc ressembler à ceci:
git log --follow -- foo
Mise à jour:
Git 2.9+ a maintenant activé cela par défaut pour tous les git diff et git log commandes:
L'utilisateur final faisant face aux commandes de niveau Porcelain dans la famille "git diff" et "git log" active par défaut la détection de renommage; vous pouvez toujours utiliser la variable de configuration "diff.renames" pour la désactiver.
Merci à x-yuri pour l'avertissement!