restaurar - revertir cambios en un archivo git

El estado de git muestra modificaciones, git checkout-<archivo> no las elimina (18)

Me gustaría eliminar todos los cambios en mi copia de trabajo.
La ejecución git status muestra 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")

¡Tengo el mismo problema dos veces! Las dos veces escondí algunos cambios que hice y luego traté de devolverlos. No puedo mostrar los cambios ya que tengo muchos archivos cambiados, ¡pero NO lo son! Son exactamente lo mismo.

Ahora creo que he intentado 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 modificar el archivo, dice que he eliminado todas las líneas y luego las vuelvo a agregar.

Tipo de inquietante. Ahora evitaré esconderme en el futuro ...

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

Aquí hay muchas soluciones y tal vez debería haber probado algunas de ellas antes de pensar en las mías. De todos modos aquí hay uno más ...

Nuestro problema era que no teníamos cumplimiento 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. La decisión fue tomada por aquellos con propiedad primaria del repositorio del sistema operativo para cambiar todas las líneas finales a Unix y se realizó el compromiso que incluía un .gitattributes para aplicar los finales de línea.

Desafortunadamente, esto parecía causar problemas muy similares a los descritos aquí donde una vez que se fusionó el código anterior al DOS-2-Unix, los archivos se marcarían para siempre como cambiados y no podrían revertirse.

Durante mi investigación sobre esto, me encontré con que: https://help.github.com/articles/dealing-with-line-endings/ - Si volvía a enfrentar este problema, primero comenzaría por probar esto.

Aquí esta lo que hice:

Inicialmente había hecho 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 combinación. ¿Cómo puedo abortar la fusión? )
Abrí los archivos en cuestión en VIM y cambié a Unix ( :set ff=unix ). Una herramienta como dos2unix podría ser utilizada en lugar de curso
comprometido
fusionó el master en (el maestro tiene los cambios DOS-2-Unix)
git checkout old-code-branch; git merge master
Los conflictos resueltos y los archivos eran DOS de nuevo, así que tenía que :set ff=unix cuando 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)
comprometido. ¡Todo ordenado!

Cometí todos los cambios y luego hice y desharía el compromiso. Esto funcionó para mí

git add.

git commit -m "Compromiso aleatorio"

git reset --hard HEAD ~ 1

El problema con el que me encontré es que Windows no se preocupa por el uso de mayúsculas de los nombres de los archivos, pero lo hace. Así que git almacenó una versión en mayúsculas y minúsculas del archivo, pero solo pudo sacar una.

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

git reset --hard git pull origin git merge

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

Esto funcionó para mí, con la idea de que dejaras que git reescribiera completamente tu directorio de trabajo:

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

(Tenga en cuenta que ejecutar solo git reset --hard no era lo suficientemente bueno, ni era una rm simple en los archivos antes del reset como se sugiere en los comentarios a la pregunta original)

Este problema también puede ocurrir cuando un colaborador del repositorio trabaja en una máquina Linux, o se cambian las ventanas con Cygwin y los permisos de archivos. 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

Esto me está volviendo loco, sobre todo 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 :)

Fuente del problema: mi instalación inicial de git no tenía conversión de línea automática en Windows. Esto causó que mi compromiso inicial con GLFW fuera sin el final de línea adecuado.

Nota: esta es solo una solución local. El siguiente tipo que clone el repositorio seguirá atascado con este problema. Se 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 muestran como modificado, independientemente de lo que probé.

Resuelto

edit .gitattributes Comment out the line: # text=auto Save the file restore .gitattributes: git checkout .gitattributes

Hay varios problemas que pueden causar este comportamiento:

Línea que finaliza la normalización

He tenido este tipo de problemas también. Todo se reduce a git convertir automáticamente crlf a lf. Esto suele ser causado por terminaciones de línea mixtas en un solo archivo. El archivo se normaliza en el índice, pero cuando git lo desnormaliza de nuevo para que se diferencie con el archivo en el árbol de trabajo, el resultado es diferente.

Pero si quiere arreglar esto, debe deshabilitar core.autocrlf , cambiar todos los finales de línea a lf, y luego habilitarlo de nuevo. O puede desactivarlo por completo haciendo:

git config --global core.autocrlf false

En lugar de core.autocrlf , también puede considerar el uso de archivos .gitattribute . De esta forma, puedes asegurarte de que todos los que usan el repositorio usen las mismas reglas de normalización, evitando que las terminaciones de línea mixta entren en el repositorio.

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

Las manpages git dicen esto:

La conversión CRLF tiene una pequeña posibilidad de corromper datos. autocrlf = true convertirá CRLF a LF durante la confirmación y de LF a CRLF durante el proceso de pago. Un archivo que contiene una mezcla de LF y CRLF antes del compromiso no puede ser recreado por git. Para los archivos de texto, esto es lo que se debe hacer: corrige los finales 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 insensibles a mayúsculas / minúsculas

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

La solución estaría cambiando a un sistema de archivos insensible a las mayúsculas y a las minúsculas, pero esto en la mayoría de los casos no es factible o al renombrar y confirmar uno de los archivos en otro sistema de archivos.

Intenta hacer una

git checkout -f

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

Nada más en esta página funcionó. Esto finalmente funcionó para mí. No muestra ningún archivo sin seguimiento ni archivos comprometidos.

git add -A git reset --hard

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

Reemplace el contenido de .gitattributes con 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.
Verifique que el mensaje para los archivos ofensivos ya no esté; si no es así, puede git checkout -- <files> para restaurarlos a la versión del repositorio
git checkout -- .gitattributes para restaurar el archivo .gitattributes a su estado inicial
Verifique que los archivos aún no estén marcados como cambiados.

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

Si clona un repositorio y ve instantáneamente cambios pendientes, entonces el repositorio está en un estado incoherente. NO haga comentarios * text=auto desde el archivo .gitattributes . Eso se puso allí específicamente porque el propietario del repositorio quiere que todos los archivos estén almacenados de manera consistente con las terminaciones de línea LF.

Según lo indicado por HankCa, siguiendo 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 rama con el propietario del repositorio.

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

git status después de eliminar y las modificaciones desaparecieron. No regresaron incluso después de que .gitattributes se puso de nuevo en su lugar.

También tuve los mismos síntomas, pero ha sido 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 firma como eliminado y en archivos sin seguimiento pude ver app.js. Pero cuando probé rm -rf app.js y peform git status otra vez, todavía me muestra el archivo en ''no rastreado''.

Después de un par de intentos con un colega, descubrimos que ¡ha sido causado por Grunt!

Como el Grunt se ha encendido, y debido a que app.js se ha generado a partir de otros dos archivos js, descubrimos que después de cada operación con archivos js (también este app.js) gruñía recrea de nuevo app.js.

Tenía un archivo .bat con el mismo problema (no pude eliminarlo en archivos sin seguimiento). git checkout - no funcionó, ni 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

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

Además, algunos programas como bash (en Linux) requieren que los archivos .sh tengan terminación LF.

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

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

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

Entonces autocrlf puede convertir los finales 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 el momento.