que - git tag name
Culpa de Git que no muestra historial (4)
Cuando ejecuto git culpa en un archivo (usando msysgit) siempre obtengo el siguiente tipo de impresión:
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
es decir, muestra todas las líneas como Aún no confirmadas.
Intenté esto en muchos archivos, que tienen muchas confirmaciones, siempre los mismos resultados. También intenté usar la ruta relativa / completa, pero parece no hacer diferencia.
Cuando trato de usar la culpa de TortoiseGit, siempre muestra cada línea como la última comprometida en la primera confirmación:
incluso pensé, como ya he dicho, en realidad hay decenas de confirmaciones en la historia de estos archivos ...
Ideas?
Editar - Más información
- La culpa de Git funciona bien en GitHub, donde se realiza este repositorio.
- También funciona bien si lo clono en una máquina Linux y culpo allí
- Parece que solo en msysgit esto no funciona
Al iniciar git 2.0.1 (25 de junio de 2014), la culpa de git debe dejar de informar todas las líneas "Aún no comprometidas".
Ver commit 4d4813a por brian m. carlson ( bk2204 ) (abril de 2014):
culpa: manejar correctamente los archivos independientemente de autocrlf
Si un archivo contenía terminaciones de línea CRLF en un repositorio con
core.autocrlf=input, entonces culpar siempre marcó las líneas como "Not Committed Yet", incluso si no se modificaron.
No intente convertir los finales de línea al crear la confirmación falsa para que la culpa funcione correctamente independientemente de la configuración de autocrlf.
Encontré la solución, muy raro.
Si ejecuto esto:
git blame file.txt
La historia está rota, como se publicó anteriormente.
Si hago esto en su lugar:
git blame my_branch file.txt
¡Funciona!
Esto es muy extraño, porque AFAICS el uso no requiere un nombre de rama:
$ git blame
usage: git blame [options] [rev-opts] [rev] [--] file
Otra posibilidad: Typo de nombre de archivo sensible a mayúsculas y minúsculas
Tuve el mismo problema con git blame file.txt, luego me di cuenta de que había hecho un tipo de archivo de nombre de archivo sensible a mayúsculas y minúsculas con file.txt
Cambié a File.txt (por ejemplo), y obtuve los resultados esperados sin tener que especificar my_branch: git culpa File.txt
git blame file.txt culpa a la versión de archivo.txt en su copia de trabajo. Si file.txt tiene Windows-newlines (CRLF) en el repositorio y tiene core.autocrlf = true , entonces cada línea de archivo.txt se considerará diferente y se informará por git blame como aún no confirmada.
La razón por la cual git blame <my_branch> (o mejor a git blame HEAD , que funciona no importa en qué rama estás) funciona, es que no culpa a la versión de copia de trabajo por lo que no hay potencial para que las líneas aún no se hayan comprometido .