Git blame ne montrant aucune histoire

Quand je lance git blame sur un fichier (en utilisant msysgit), j'obtiens toujours le type d'impression suivant:

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'est-à-dire qu'il montre toutes les lignes comme pas encore engagées.

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

Quand j'essaye d'utiliser le blâme de TortoiseGit, il montre toujours chaque ligne comme étant la dernière commise au premier commit:

même pensé, comme je l'ai dit, il y a en fait des dizaines de commits dans l'historique de ces fichiers.

Des idées?

Modifier - Plus d'informations

• Git blame fonctionne bien sur GitHub, où ce dépôt est hébergé.
• Cela fonctionne également très bien si je le clone sur une machine Linux et que je blâme là-bas
• Il semble que cela ne fonctionne que sur msysgit

git blame file.txtblâme la version de file.txt dans votre copie de travail. Si file.txt a Windows-newlines (CRLF) dans le dépôt et que vous en avez core.autocrlf = true, alors chaque ligne de file.txt sera considérée comme différente et sera signalée par git blamecomme non encore validée.

La raison pour laquelle git blame <my_branch>(ou même mieux git blame HEAD, qui fonctionne quelle que soit la branche sur laquelle vous vous trouvez) fonctionne, c'est qu'il ne blâme pas la version de la copie de travail, donc il n'y a aucun potentiel pour les lignes non encore validées.

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

Si je lance ceci:

git blame file.txt

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

Si je fais cela à la place:

git blame my_branch file.txt

Ça marche!

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

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

À 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- dans commit e934c67 , 06 juin 2014)}

blame: gérer correctement les fichiers indépendamment de autocrlf

Si un fichier contenait des CRLFfins de ligne dans un référentiel avec core.autocrlf=input, alors blâmez toujours les lignes marquées comme " Not Committed Yet", même si elles n'ont pas été modifiées.
N'essayez pas de convertir les fins de ligne lors de la création du faux commit afin que le blâme fonctionne correctement quel que soit le autocrlfparamètre.

Une autre possibilité: typo de nom de fichier sensible à la casse

J'ai eu le même problème avec git blame file.txt, puis j'ai réalisé que j'avais créé une typo de nom de fichier sensible à 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 my_branch: git blame File.txt