el estado de git muestra modificaciones, pago de git - <archivo> no las elimina

Me gustaría eliminar todos los cambios en mi copia de trabajo.
La ejecución git statusmuestra archivos modificados.
Nada de lo que hago parece eliminar estas modificaciones.
P.ej:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Existen múltiples problemas que pueden causar este comportamiento:

Normalización de final de línea

También he tenido este tipo de problemas. Se reduce a git convirtiendo automáticamente crlf a lf. Esto generalmente es causado por terminaciones de línea mixtas en un solo archivo. El archivo se normaliza en el índice, pero cuando git lo desnormaliza nuevamente para diferenciarlo del archivo en el árbol de trabajo, el resultado es diferente.

Pero si quieres arreglar esto, debes deshabilitar core.autocrlf , cambiar todas las terminaciones de línea a lf y luego habilitarlo nuevamente. O puede deshabilitarlo por completo haciendo:

git config --global core.autocrlf false

En vez de core.autocrlf , también puede considerar el uso de .gitattributearchivos. De esta manera, puede asegurarse de que todos los que usan el repositorio usen las mismas reglas de normalización, evitando que las terminaciones de líneas mixtas ingresen al repositorio.

También considere configurar core.safecrlf para advertir si desea que git le avise cuando se realice una normalización no reversible.

El imbécil páginas de manual de dicen esto:

La conversión de CRLF tiene una pequeña posibilidad de corromper los datos. autocrlf = true convertirá CRLF a LF durante la confirmación y LF a CRLF durante el pago. Un archivo que contiene una mezcla de LF y CRLF antes de la confirmación no puede ser recreado por git. Para los archivos de texto, esto es lo correcto: corrige las terminaciones de línea de modo que solo tengamos terminaciones de línea LF en el repositorio. Pero para los archivos binarios que se clasifican accidentalmente como texto, la conversión puede dañar los datos.

Sistemas de archivos que no distinguen entre mayúsculas y minúsculas

En los sistemas de archivos que no distinguen entre mayúsculas y minúsculas, cuando el mismo nombre de archivo con una carcasa diferente está en el repositorio, git intenta verificar ambos, pero solo uno termina en el sistema de archivos. Cuando git intenta comparar el segundo, lo compararía con el archivo incorrecto.

La solución sería cambiar a un sistema de archivos que no distinga entre mayúsculas y minúsculas, pero esto en la mayoría de los casos no es factible o renombrar y comprometer uno de los archivos en otro sistema de archivos.

Estaba teniendo este problema en Windows, pero no estaba preparado para analizar las ramificaciones del uso config --global core.autocrlf false. Tampoco estaba preparado para abandonar otras ramas privadas y otras cosas en mi escondite y comenzar con un nuevo clon. Solo necesito hacer algo. Ahora.

Esto funcionó para mí, con la idea de que dejas que git reescriba tu directorio de trabajo por completo:

git rm --cached -r .
git reset --hard

(Tenga en cuenta que ejecutar simplemente git reset --hardno era lo suficientemente bueno ni era simple rmen los archivos antes de lo resetque se sugiere en los comentarios a la pregunta original)

Otra solución que puede funcionar para las personas, ya que ninguna de las opciones de texto funcionó para mí:

1. Reemplace el contenido de .gitattributescon una sola línea:* binary . Esto le dice a git que trate cada archivo como un archivo binario con el que no puede hacer nada.
2. Verifique que el mensaje de los archivos ofensivos haya desaparecido; si no es así, puede git checkout -- <files>restaurarlos a la versión del repositorio
3. git checkout -- .gitattributes para restaurar el .gitattributes archivo a su estado inicial
4. Compruebe que los archivos todavía no están marcados como modificados.

Para futuras personas que tienen este problema: Tener cambios en el modo de archivo también puede tener los mismos síntomas. git config core.filemode falselo arreglará

Esto me ha vuelto loco, especialmente porque no podría solucionarlo sin ninguna de las soluciones que se encuentran en línea. Así es como lo resolví. No puedo tomar los créditos aquí ya que este es el trabajo de un colega :)

Origen del problema: mi instalación inicial de git fue sin conversión automática de línea en Windows. Esto causó que mi confirmación inicial a GLFW no tuviera el final de línea adecuado.

Nota: Esta es solo una solución local. El próximo tipo que clone el repositorio seguirá estancado con este problema. Puede encontrar una solución permanente aquí: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Configuración: Xubuntu 12.04 Git repo con proyecto glfw

Problema: no se pueden restablecer los archivos glfw. Siempre se muestran como modificados, independientemente de lo que intenté.

Resuelto:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Tenía un archivo .bat con el mismo problema (no podía eliminarlo en archivos sin seguimiento). git checkout: no funcionó, tampoco ninguna de las sugerencias en esta página. Lo único que funcionó para mí fue hacer:

git stash save --keep-index

Y luego para eliminar el alijo:

git stash drop

¡Tengo el mismo problema dos veces! Ambas veces cuando escondí algunos cambios que hice y luego traté de recuperarlos. No pude hacer estallar los cambios ya que tengo muchos archivos que se han cambiado, ¡pero NO! Son exactamente lo mismo.

Ahora creo que he probado todas las soluciones anteriores sin éxito. Después de probar el

git rm --cached -r .
git reset --hard

Ahora tengo casi todos los archivos en mi repositorio modificados.

Al diferenciar el archivo, dice que he eliminado todas las líneas y luego las agrego nuevamente.

Un poco inquietante. Ahora evitaré esconderme en el futuro.

La única solución es clonar un nuevo repositorio y comenzar de nuevo. (Lo hice la última vez)

Intenta hacer un

git checkout -f

Eso debería eliminar todos los cambios en el repositorio local de trabajo actual

Solo pude solucionar esto eliminando temporalmente el archivo .gitattributes de mi repositorio (que definió * text=autoy *.c text).

Corrí git statusdespués de eliminar y las modificaciones desaparecieron. No regresaron incluso después de que .gitattributes se volviera a colocar en su lugar.

Tener finales de línea consistentes es algo bueno. Por ejemplo, no activará fusiones innecesarias, aunque triviales. He visto a Visual Studio crear archivos con terminaciones de línea mixtas.

Además, algunos programas como bash (en linux) requieren que los archivos .sh estén terminados en LF.

Para asegurarse de que esto suceda, puede usar gitattributes. Funciona a nivel de repositorio sin importar el valor de autcrlf.

Por ejemplo, puede tener atributos .gitat como este: * text = auto

También puede ser más específico por tipo / extensión de archivo si importa en su caso.

Entonces, autocrlf puede convertir terminaciones de línea para programas de Windows localmente.

En un proyecto mixto C # / C ++ / Java / Ruby / R, Windows / Linux, esto funciona bien. No hay problemas hasta ahora.

También tuve los mismos síntomas, pero fue causado por algo diferente.

Yo no era capaz de:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

incluso en git rm --cached app.jsél firma como eliminado y en archivos sin seguimiento pude ver app.js. Pero cuando intenté rm -rf app.jsy volví git statusa peform , todavía me muestra el archivo en 'sin seguimiento'.

Después de un par de intentos con un colega, descubrimos que fue causado por Grunt.

A medida que Gruntse ha activado, y debido a que app.js se ha generado a partir de un par de otros archivos js, descubrimos que después de cada operación con archivos js (también este app.js) Grunt recrea nuevamente app.js.

Este problema también puede ocurrir cuando un contribuyente al repositorio trabaja en una máquina Linux, o las ventanas con Cygwin y los permisos de archivo cambian. Git solo sabe de 755 y 644.

Ejemplo de este problema y cómo verificarlo:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Para evitar esto, debes asegurarte de configurar git correctamente usando

git config --global core.filemode false

Aquí hay muchas soluciones y tal vez debería haber intentado algunas de ellas antes de encontrar la mía. De todos modos aquí hay uno más ...

Nuestro problema era que no teníamos aplicación para las líneas finales y el repositorio tenía una mezcla de DOS / Unix. Peor aún era que en realidad era un repositorio de código abierto en esta posición, y que habíamos bifurcado. Aquellos con la propiedad principal del repositorio del sistema operativo tomaron la decisión de cambiar todas las líneas finales a Unix y se realizó la confirmación que incluía una .gitattributespara hacer cumplir las terminaciones de línea.

Desafortunadamente, esto parecía causar problemas muy parecidos a los descritos aquí, donde una vez que se fusionó el código antes del DOS-2-Unix, los archivos se marcarían para siempre como modificados y no se podrían revertir.

Durante mi investigación para esto, me encontré con: https://help.github.com/articles/dealing-with-line-endings/ - Si me enfrento a este problema nuevamente, primero comenzaría probando esto.

Aquí esta lo que hice:

1. Inicialmente hice una fusión antes de darme cuenta de que tenía este problema y tuve que abortarlo git reset --hard HEAD( me encontré con un conflicto de fusión. ¿Cómo puedo abortar la fusión? )

2. Abrí los archivos en cuestión en VIM y cambié a Unix ( :set ff=unix). Se dos2unixpodría usar una herramienta como

3. comprometido

4. fusionó la entrada master(el maestro tiene los cambios de DOS-2-Unix)

   git checkout old-code-branch; git merge master

5. Se resolvieron los conflictos y los archivos volvieron a ser DOS, así que tuve que hacerlo :set ff=unixcuando estaba en VIM. (Tenga en cuenta que he instalado https://github.com/itchyny/lightline.vim que me permitió ver cuál es el formato del archivo en la línea de estado de VIM)

6. comprometido. ¡Todo ordenado!

El problema con el que me encontré es que Windows no se preocupa por la capitalización del nombre de archivo, pero git sí. Entonces, git almacenó una versión en mayúsculas y minúsculas del archivo, pero solo pudo verificar una.

Cometí todos los cambios y luego hice y deshago el commit. Esto funciono para mi

git add.

git commit -m "Confirmación aleatoria"

git reset --HAD HEAD ~ 1

Normalmente, en GIT para borrar todas sus modificaciones y archivos nuevos, los siguientes 2 comandos deberían funcionar muy bien (tenga cuidado , esto eliminará todos sus nuevos archivos + carpetas que haya creado y restaurará todos sus archivos modificados al estado de su actual commit ):

$ git clean --force -d
$ git checkout -- .

Tal vez una mejor opción a veces es simplemente hacer "git stash push" con un mensaje opcional, así:

$ git stash push -m "not sure if i will need this later"

Esto también borrará todos sus archivos nuevos y modificados, pero los tendrá escondidos en caso de que desee restaurarlos. El almacenamiento en GIT se lleva de una rama a otra, por lo que puede restaurarlos en una rama diferente, si lo desea.

Como nota al margen, en caso de que ya haya montado algunos archivos recién agregados y desee deshacerse de ellos, esto debería ser el truco:

$ git reset --hard

Si todo lo anterior no funciona para usted , lea a continuación lo que funcionó para mí hace un tiempo:

Me encontré con este problema varias veces antes. Actualmente estoy desarrollando en una máquina con Windows 10 proporcionada por mi empleador. Hoy, este comportamiento particular de git fue causado por crear una nueva rama de mi rama "desarrollar". Por alguna razón, después de que volví a "desarrollar" la rama, algunos archivos aparentemente aleatorios persistieron y aparecían como "modificados" en "estado de git".

Además, en ese momento no podía pagar otra rama, por lo que estaba atascado en mi rama "desarrollar".

Esto es lo que hice:

$ git log

Me di cuenta de que la nueva rama que creé desde "desarrollo" el día de hoy se mostraba en el primer mensaje de "confirmación", al que se hace referencia al final "HEAD -> desarrollo, origen / desarrollo, origen / CABEZA, The-branch-i-created -el día de hoy ".

Como realmente no lo necesitaba, lo eliminé:

$ git branch -d The-branch-i-created-earlier-today

Los archivos modificados seguían apareciendo, así que lo hice:

$ git stash

Esto resolvió mi problema:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Por supuesto $ git stash list, mostrará los cambios escondidos, y como tenía pocos y no necesitaba ninguno de mis escondites, lo hice $ git stash clearpara ELIMINAR TODOS LOS STASHES.

NOTA : No he intentado hacer lo que alguien sugirió aquí antes que yo:

$ git rm --cached -r .
$ git reset --hard

Esto puede haber funcionado también, me aseguraré de intentarlo la próxima vez que me encuentre con este problema.

Si clona un repositorio y ve instantáneamente los cambios pendientes, entonces el repositorio está en un estado inconsistente. Por favor NO comente * text=autodesde el.gitattributes archivo. Eso se puso allí específicamente porque el propietario del repositorio quiere que todos los archivos se almacenen de manera consistente con las terminaciones de línea LF.

Según lo indicado por HankCa, seguir las instrucciones en https://help.github.com/articles/dealing-with-line-endings/ es el camino a seguir para solucionar el problema. Botón fácil:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Luego combine (o solicite) la sucursal con el propietario del repositorio.

Nada más en esta página funcionó. Esto finalmente funcionó para mí. No muestra archivos no rastreados o comprometidos.

git add -A
git reset --hard

Para mí, el problema fue que Visual Studio se abrió al ejecutar el comando

git checkout <file>

Después de cerrar Visual Studio, el comando funcionó y finalmente pude aplicar mi trabajo desde la pila. Por lo tanto, verifique todas las aplicaciones que puedan realizar cambios en su código, por ejemplo, SourceTree, SmartGit, NotePad, NotePad ++ y otros editores.

Nos enfrentamos a una situación similar en nuestra empresa. Ninguno de los métodos propuestos no nos ayudó. Como resultado de la investigación, se reveló el problema. Lo que pasaba era que en Git había dos archivos, cuyos nombres solo diferían en el registro de símbolos. Los sistemas Unix los veían como dos archivos diferentes, pero Windows se estaba volviendo loco. Para resolver el problema, eliminamos uno de los archivos del servidor. Después de eso, en los repositorios locales en Windows ayudó a los siguientes comandos (en diferentes secuencias):

git reset --hard
git pull origin
git merge

Lo resolví editando .git / config, agregando:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Luego fui a .git / refs / heads / name_branch y coloqué la identificación del último commitenter code here

Lo resolví de esta manera:

1. Copie el contenido del código correcto que desee
2. Elimine el archivo que está causando el problema (el que no puede revertir) de su disco. ahora debería encontrar ambas versiones del mismo archivo marcadas como eliminadas.
3. Confirmar la eliminación de los archivos.
4. Vuelva a crear el archivo con el mismo nombre y pegue el código correcto que copió en el paso 1
5. comprometer la creación del nuevo archivo.

Eso fue lo que funcionó para mí.

Una solución propuesta aquí no funcionó, descubrí que el archivo era en realidad un enlace a algunos caracteres especiales:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png