tag - git ver archivos modificados
Parece que no puede descartar los cambios en Git (13)
Después de ver lo siguiente desde la línea de comando:
# On branch RB_3.0.10
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.htm
Estoy tratando de descartar mis cambios escribiendo el comando:
git checkout -- index.htm
pero cuando vuelvo a ejecutar el estado de git, se ve exactamente igual. El pago no parece estar funcionando. ¿Estoy haciendo algo mal? Estoy usando GIT 1.6.1.2 en windows / cygwin.
# On branch RB_3.0.10
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.htm
¿Estás en OSX o Windows? Si es así, el problema probablemente sea tener dos archivos del mismo nombre, con un caso diferente. p.ej. index.htm e Index.htm
Windows, y por defecto OSX, usa un sistema de archivos que no distingue entre mayúsculas y minúsculas, lo que entra en conflicto con el git sensible a las mayúsculas y minúsculas.
¿Qué cambios muestra git diff
en el archivo? En Windows, he visto problemas con los finales de línea que causan problemas como este. En ese caso, observe qué configuraciones tiene para git config core.autocrlf
y git config core.safecrlf
. Aquí hay algo de documentación para estas configuraciones .
Yo diría que si está utilizando git svn
para la integración con subversion, entonces asegúrese de que autocrlf
esté desactivado. Por lo que puedo decir, está roto en esta configuración y hace que la mayoría de las herramientas piensen que los archivos han sido cambiados, cuando has hecho un checkout
para revertir cualquier cambio.
Si ve un problema al hacer la git checkout
, y luego el git status
muestra que el archivo se sigue modificando, y git diff
muestra que el archivo está modificado en cada línea del archivo, entonces este es el problema que está viendo.
core.autocrlf
Si es verdadero, hace que git convierta CRLF al final de las líneas en archivos de texto a LF cuando lee desde el sistema de archivos, y convierte al revés al escribir en el sistema de archivos. La variable se puede configurar para ingresar, en cuyo caso la conversión solo se produce al leer desde el sistema de archivos, pero los archivos se escriben con LF al final de las líneas. Actualmente, las rutas para considerar "texto" (es decir, estar sujeto al mecanismo autocrlf) se deciden puramente en función de los contenidos.
core.safecrlf
Si es verdadero, hace que git compruebe si la conversión de CRLF controlada por core.autocrlf es reversible. Git verificará si un comando modifica un archivo en el árbol de trabajo directa o indirectamente. Por ejemplo, si se compromete un archivo seguido de la extracción del mismo archivo, se obtendrá el archivo original en el árbol de trabajo. Si este no es el caso para la configuración actual de core.autocrlf, git rechazará el archivo. La variable se puede establecer en "warn", en cuyo caso git solo advertirá sobre una conversión irreversible pero continuará la operación. ...
Aquí está mi experiencia, establezca las siguientes variables en .git/config
:
[core]
autocrlf = false
safecrlf = false
eol = crlf
luego ejecute $ git checkout HEAD .
, y funciona. pero $ git checkout -- .
¡no es extraño!
* git versión 1.9.3
Creo que necesitas pasar -f
Desde la página man ( man git-checkout
, GIT-CHECKOUT (1)):
-f, --force
Proceda incluso si el índice o el árbol de trabajo difieren de HEAD.
Esto se usa para desechar los cambios locales .
Por ejemplo, descartar cambios en la rama actual y cambiar a una rama diferente:
git checkout -f master
En mi caso, no pude descartar los cambios relacionados con un directorio. por ejemplo, cuando ejecutaba un git diff, veía esto: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Así que llamé a ese directorio y ejecuté un estado de git allí. Estaba en un estado separado de HEAD. Y luego acabo de ejecutar un git checkout master
allí. Eso hizo las cosas bien para mí. Pero esto no es útil para el escenario exacto que se pregunta aquí.
Esta es una vieja pregunta, pero todavía era relevante para mí. No encontré mi respuesta hasta que pregunté por la oficina y descubrí que el problema era con los submódulos. Cuando se actualizan y su propio repositorio no refleja esos cambios, aparece como que tienen diferencias, restablecer el encabezado no ayuda. Si este es el caso, ejecuta:
git status update
Eso debería ayudar a arreglar las cosas (en este caso particular)
Esto me ha estado molestando por un tiempo, casi todos los informes que revisaba tenían cambios que no podía descartar. Para resumir, probé todo lo anterior, nada funcionó. Esto es lo que hice para que todo vuelva a la normalidad (en una Mac):
Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo''s local config ./.git/config
git rm --cached -r .
git reset --hard
Hay una solución fácil. Si esto sucede (normalmente desde el cierre inesperado de Windows o el volcado de memoria) y no puede descartar los cambios e incluso cambiar de rama (Git dice que no tiene suficiente permiso); en Windows
entorno de Windows
, show all hidden files and folders
de las opciones de carpeta. Vaya a su directorio GIT (debe comenzar con .git
) y elimine el archivo "index.lock"
. Entonces Git debería dejarte hacer lo que quieras hacer.
Pueden ser finales de línea, como @ 1800-sugiere la información, pero otra posibilidad es que la diferencia (que le impide revertir estos archivos con un comando de finalización) es una de modo de archivo. Esto es lo que me pasó a mí. En mi versión de git puedes descubrir esto usando
git diff index.htm
Y le mostrará los cambios del modo de archivo. Sin embargo, aún no le permitirá revertirlos mediante el pago, incluso con la opción -f. Para ese uso, ya sea
git config core.filemode false
o cambia tu git .config en tu editor de texto agregando
[núcleo]
filemode = false
Después de hacer esto, puede usar
git reset HEAD index.htm
y el archivo debería desaparecer
(Obtuve todo esto de las respuestas a ¿Cómo hago que git ignore los cambios de modo (chmod)? Y updating-file-permissions-only-in-git )
También me enfrenté a un problema similar y los siguientes pasos me ayudaron:
git commit -am ''temp commit''
git pull origin master
git reset head~1
git reset head --hard
Espero que ayude a otras personas también.
Terminé haciendo un git stash
seguido de un git stash clean
para deshacerme de algunos. No vi ninguna configuración auto cr / lf en las cosas de .git / o ~ / .git.
Tuve este problema y después de probar todo lo anterior, nada funcionó.
Lo que funcionó para mí fue eliminar el directorio en el que se encontraba el archivo, luego git status
y me aseguré de que todos los archivos de ese directorio estén ahora marcados como eliminados. Después de eso, simplemente hice la git checkout -f
y todo volvió a la normalidad.
Tuve un problema similar, en el que no me permitía descartar archivos que no existen o que se han modificado. Uso Visual Studio en el trabajo, y descubrí que esto sucede cuando se cambian las sucursales mientras la aplicación se está ejecutando.
git checkout
e intento de descartar no ayudaron. No funcionaría o simplemente me diría que no tengo permiso.
Solución que funcionó:
- Entrar en modo seguro
- Descartar archivos
Reiniciar es un dolor, pero funcionó más rápido que probar 100 cosas.