blâme git montrant pas d'histoire

Question

Quand je lance le blâme git sur un fichier (en utilisant msysgit) Je reçois toujours les suivantes sorte d'impression:

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

i.e.. il montre que toutes les lignes non encore engagées.

J'ai essayé sur plusieurs dossiers, qui ont beaucoup de commits - toujours les mêmes résultats. J'ai aussi essayé d'utiliser le chemin relatif / complet, mais il semble faire aucune différence.

Lorsque je tente d'utiliser le blâme TortoiseGit il montre toujours chaque ligne comme étant la dernière engagée au premier commit:

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

Idées?

Modifier - Plus d'infos

• blâme Git fonctionne très bien sur GitHub, où cette prise en pension est hébergé.
• Il fonctionne aussi bien si je clone à une machine linux et faire le blâme là
• Il semble que seulement sur msysgit cela ne fonctionne pas

Answer 1

git blame file.txt accuse la version de file.txt dans votre copie de travail. Si file.txt a à Windows (CRLF) des sauts de ligne dans la prise en pension et que vous avez core.autocrlf = true, puis chaque ligne de file.txt sera considéré comme différent et sera rapporté par git blame comme pas encore commis.

La raison pour laquelle git blame <my_branch> (ou mieux encore git blame HEAD, qui fonctionne peu importe quelle branche vous êtes) fonctionne, est qu'il ne blâme pas la version copie de travail donc il n'y a pas de potentiel pour les lignes non encore commises.

Answer 2

trouvé la solution -. Très bizarre

Si je lance ceci:

git blame file.txt

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

Si je fais ceci:

git blame my_branch file.txt

Il fonctionne!

Ceci est très bizarre, parce que AFAICS l'utilisation ne nécessite pas de nom de la branche:

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

Answer 3

À partir git 2.0.1 (le 25 Juin, 2014), le blâme git devrait cesser tous ces rapports "Pas encore" Engagés lignes.

Voir commettre 4d4813a (26 avril 2014) par brian m. carlson (bk2204) .
^{(Fusionné par Junio ??Hamano C - gitster - commit e934c67 , 6 juin 2014)}

  

blame: gérer correctement les fichiers quel que soit autocrlf

     

Si un fichier contenait les fins de ligne de CRLF dans un dépôt avec core.autocrlf=input, alors blâmer les lignes toujours marquées comme « Not Committed Yet », même si elles étaient non modifiées.
  Ne tentez pas de convertir les fins de ligne lors de la création du faux commit alors que le blâme fonctionne correctement quel que soit le réglage autocrlf.

Answer 4

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

J'ai eu le même problème avec file.txt blâme git, alors réalisé que je l'avais fait un nom de fichier sensible à la casse faute de frappe avec file.txt

Changement à Fichier.txt (par exemple), et j'ai obtenu les résultats attendus w / o avoir à spécifier my_branch: blâme git Fichier.txt