web-dev-qa-db-fra.com

Git blame montrant aucune histoire

Lorsque j'exécute 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 affiche toutes les lignes comme non encore validé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 faire aucune différence.

Lorsque j'essaie d'utiliser le blâme de TortoiseGit, il montre toujours que chaque ligne a été validée pour la dernière fois lors du premier commit:

alt text

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

Des idées?

Modifier - Plus d'infos

  • Git blame fonctionne très 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 j'en blâme
  • Il semble que cela ne fonctionne pas que sur msysgit
gitmsysgitblame
88
Assaf Lavie

git blame file.txt blâme la version de file.txt dans votre copie de travail. Si file.txt contient des sauts de ligne Windows (CRLF) dans le référentiel et que vous avez core.autocrlf = true, chaque ligne de fichier.txt sera considérée comme différente et sera signalée par git blame comme non 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 travaillez), est qu'il ne blâme pas la version de copie de travail, il n'y a donc pas de potentiel pour que les lignes ne soient pas encore validées.

126
kusma

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

Si je lance ceci:

git blame file.txt

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

Si je fais cela à 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
55
Assaf Lavie

À partir de git 2.0.1 (25 juin 2014), git blame devrait cesser de signaler toutes ces lignes "Pas encore validées".

Voir commit 4d4813a (26 avril 2014) par brian m. Carlson (bk2204) .
(Fusionné par Junio ​​C Hamano - gitster - in commit e934c67 , 06 juin 2014)

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

Si un fichier contient CRLF fins de ligne dans un référentiel avec core.autocrlf=input, puis blâmez toujours les lignes marquées 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 quel que soit le paramètre autocrlf.

7
VonC

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 fait une faute de frappe sensible à la casse avec file.txt

Changé en File.txt (par exemple), et j'ai obtenu les résultats attendus sans avoir à spécifier my_branch: git blame File.txt

1
John Jacecko