Git blame ne montrant aucune histoire

88

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:

texte alternatif

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 windows-subsystem-for-linux msysgit blame Assaf Lavie
la source
Pour moi, ce problème résultait de l'utilisation d'un chemin de lien symbolique associé à un chemin que le référentiel reconnaissait, donc il pensait que le fichier était complètement nouveau.
Kzqai
Remarque: à partir de git 2.0.1 (25 juin 2014), git blame devrait cesser de signaler toutes ces lignes "Not Yet Committed". Voir ma réponse ci
VonC
Sur la liste de diffusion: git.661346.n2.nabble.com /... Cela se produit également sous Linux.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
Cela affecte également WSL, j'ai donc ajouté la balise. J'espère que ça va.
mikemaccana

Réponses:

126

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.

kusma
la source
117
git blame -wignore les espaces, donc vous pouvez toujours blâmer la copie de travail si vous le souhaitez
Kyle Heironimus
13
Git blame -w devrait être une réponse séparée et la réponse acceptée;). La réponse acceptée sans le commentaire était inutile pour moi.
Guillaume Perrot le
55

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
Assaf Lavie
la source
7
Cela fonctionne pour moi, merci de l'avoir posté. Vous devez marquer celui-ci comme la réponse IMO.
wes
Cela fonctionne pour moi dans msysgit mais le nom de fichier est sensible à la casse. Donc je peux écrire git blame mybranch cmakelists.txtet ça échouera; mais si j'écris, git blame mybranch CMakeLists.txtcela fonctionnera.
boucle
Je suis d'accord, wes; le blâme ne montrait aucun historique jusqu'à ce que je spécifie la branche, ce qui est incompatible avec la documentation.
josephdpurcell
OMG, le blâme est tellement cassé.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
8

À 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.

VonC
la source
8
J'ai toujours le problème dans git v2.1.3
DBedrenko
J'ai le problème avec git version 2.16.1.windows.1
Radon8472
@ Radon8472 Pouvez-vous ajouter une nouvelle question illustrant le problème, avec votre git config -lsortie (et un lien vers cette réponse): cela me permettra, ainsi qu'à d'autres, d'essayer de voir si le problème persiste.
VonC
1

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

John Jacecko
la source