Pourquoi "git log -- foo" ne fonctionne pas pour le fichier supprimé foo ?

Question

Mon référentiel a subi des changements tels que :

1. ...quelques engagements sans rapport...
2. Valider le nouveau fichier foo avec 100 lignes de contenu
3. ... des engagements intermédiaires, dont certains touchent... foo ...
4. Insérez le contenu de foo au début d'un fichier existant bar et git rm foo dans le même commit
5. ...d'autres engagements sans rapport...

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 aucun résultat.

Si je trouve le commit qui inclut la suppression 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 sorties 1234abcd[...] donc je pense que cela devrait prouver que le commit est accessible à partir de HEAD . Notez qu'il n'y a pas de fichier foo dans mon arbre de travail (évident, puisqu'il a été supprimé). J'utilise Git 1.7.1.1 sur OS X.

Pourquoi est-ce que git log -- foo fonctionne pour moi et comment puis-je le réparer ? Merci !

Answer 1

Vous voulez utiliser le --follow option sur git log qui est décrit dans la page de manuel comme :

Continue listing the history of a file beyond renames.

En effet, cela vous permet non seulement de voir l'historique d'un fichier renommé, mais aussi de voir l'historique d'un fichier qui ne se trouve plus dans l'arbre de travail. Ainsi, la commande que vous devriez utiliser devrait ressembler à quelque chose comme :

git log --follow -- foo

Answer 2

Un billet de juillet 2010 de François Marier montre une option permettant d'identifier les commits git par leur contenu,

http://feeding.cloud.geek.nz/2010/07/querying-deleted-content-in-git.html

git log --oneline -S'foo'