Git blâmé ne montrant aucune histoire

Question

Lorsque je lance git blame sur un fichier (en utilisant msysgit), j'obtiens toujours le genre d'impression suivante :

00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   1) package co
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   2) {
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   3)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   4)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   5)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   6)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   7)      impor

c.-à-d. qu'il montre toutes les lignes comme Non encore engagées.

J'ai essayé cela sur de nombreux fichiers, qui ont beaucoup de commits - toujours les mêmes résultats. J'ai également essayé d'utiliser le chemin relatif/complet, mais cela ne semble faire aucune différence.

Quand j'essaie d'utiliser le reproche de TortoiseGit, il montre toujours chaque ligne comme étant le dernier commit au premier commit :

même si, comme je l'ai dit, il y a en fait des dizaines de commits dans l'histoire de ces fichiers

Des idées ?

Editer - Plus d'informations

• Le blâme de Git fonctionne bien sur GitHub, où ce repo est hébergé.
• Il fonctionne également très bien si je le clone sur une machine linux et que j'y effectue les corrections.
• Il semble que cela ne fonctionne pas uniquement sur msysgit.

Answer 1

git blame file.txt blâme la version de file.txt dans votre copie de travail. Si file.txt a des retours à la ligne Windows (CRLF) dans le repo et que vous avez core.autocrlf = true alors chaque ligne de file.txt sera considérée comme différente et sera signalée par git blame comme n'étant pas encore engagé.

La raison pour laquelle git blame <my_branch> (ou encore mieux git blame HEAD (qui fonctionne quelle que soit la branche sur laquelle vous vous trouvez) fonctionne, c'est qu'elle ne met pas en cause la version de la copie de travail et qu'il n'y a donc pas de risque que des lignes ne soient pas encore validées.

Answer 2

J'ai trouvé la solution - très bizarre.

Si j'exécute ça :

git blame file.txt

L'historique est cassé, comme indiqué ci-dessus.

Si je fais ça à la place :

git blame my_branch file.txt

Ça marche !

C'est très bizarre, car AFAICS l'utilisation ne nécessite pas de nom de branche :

$ git blame
usage: git blame [options] [rev-opts] [rev] [--] file

Answer 3

À partir de git 2.0.1 (25 juin 2014), git blame devrait cesser de signaler toutes ces lignes " Not Yet Committed ".

Voir commit 4d4813a (26 avril 2014) par brian m. carlson ( bk2204 ) .
(fusionné par Junio C Hamano -- gitster -- en commettre e934c67 , 06 Jun 2014)

blame : traiter correctement les fichiers indépendamment de autocrlf

Si un fichier contient CRLF les terminaisons de ligne dans un référentiel avec core.autocrlf=input alors la faute a toujours marqué les lignes comme " Not Committed Yet ", même s'ils n'ont pas été modifiés.
N'essayez pas de convertir les fins de ligne lors de la création du faux commit afin que le blâme fonctionne correctement indépendamment de l'option autocrlf réglage.

Answer 4

Une autre possibilité : une erreur de frappe dans le nom du fichier en fonction de la casse.

J'ai eu le même problème avec git blame file.txt, puis j'ai réalisé que j'avais fait une faute de frappe sur le nom de fichier en respectant la casse avec file.txt.

Je l'ai changé en File.txt (par exemple), et j'ai obtenu les résultats attendus sans avoir à spécifier ma branche : git blame File.txt