Los cambios sin clasificar quedan después del restablecimiento de git --hard


275

Después git reset --hard, git statusme da archivos dentro de la Changes not staged for commit:sección.

También lo he intentado git reset ., git checkout -- .y fue git checkout-index -f -aen vano.

Entonces, ¿cómo puedo deshacerme de esos cambios no organizados?

Esto parece afectar solo a los archivos de proyecto de Visual Studio. Extraño. Vea esta pasta: http://pastebin.com/eFZwPn9Z . Lo que es especial con esos archivos es que en .gitattributes tengo:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Además, autocrlfse establece en falso en mi global .gitconfig. ¿Podría ser de alguna manera relevante?


¿Aplicaste esos comandos desde la raíz del repositorio? Aviso .significa directorio actual, no directorio raíz
Alexander

1
Los hice desde el repositorio raíz de hecho.
Norswap

Cual es tu gitversion ¿Estás cometiendo un error tonto o tienes una versión antigua que tiene errores?
Shahbaz

Es git 1.7.4 msysgit. Puede ser un error, pero los comandos parecen bastante simples, y no pude detectar un error.
Norswap

Para el registro, intenté usar la última versión de msysgit (1.7.11), pero el problema persiste.
Norswap

Respuestas:


361

Tuve el mismo problema y estaba relacionado con el .gitattributesarchivo. Sin embargo, el tipo de archivo que causó el problema no se especificó en .gitattributes.

Pude resolver el problema simplemente ejecutando

git rm .gitattributes
git add -A
git reset --hard

77
Es la directiva * text = auto en el archivo gitattributes. Cambia automáticamente las terminaciones de los archivos, por lo que los archivos se marcarán automáticamente como "modificados" cuando verifique el estado.
Cody Django

3
Esto funciona, pero no entiendo exactamente por qué. ¿Alguien quiere explicar cada comando?
Edwin Stoteler

18
@NLwino, git rm .gitattributeselimina .gitattributes del índice. git add -Aagrega todo (incluida la eliminación de .gitattributes) al índice, que entonces debería ser solo la eliminación de .gitattributes, si ese fuera realmente el problema. git reset --hardrestablece todos los cambios no confirmados, que incluirían la eliminación de .gitattributes. Esencialmente, esto ignora los atributos .gitattributes (y la * text=autodirectiva) para un commit al eliminarlo, luego restablecer el índice mientras se elimina, por lo tanto, volver a colocarlo, pero después de que ya haya restablecido los otros archivos, no se modificaron nuevamente.
cloudworks

44
@GameScripting, esta solución no funciona para mí. No existe un archivo como .gitattributes: "fatal: pathpec '.gitattributes' no coincide con ningún archivo"
Pacerier

44
Hago eso y dice fatal: pathspec '.gitattributes' did not match any files . ¿Qué estoy haciendo mal?
Miel

136

¡¡¡RESUELTO!!!

He resuelto este problema usando los siguientes pasos

1) Eliminar todos los archivos del índice de Git.

git rm --cached -r .

2) Reescribe el índice Git para recoger todas las nuevas terminaciones de línea.

git reset --hard

La solución fue parte de los pasos descritos en el sitio git https://help.github.com/articles/dealing-with-line-endings/


55
¡ESTO FUNCIONA cuando nada más lo hace! Hemos intentado todo en este y muchos otros hilos: es un gran equipo de desarrollo, por lo que poner a todos en la misma situación ha sido una pesadilla, pero esto resuelve el problema.
tkersh

Interesante ... Utilicé "git rm --chached <one_specific_file>, en lugar de eliminarlo todo." Git status "informó que el archivo fue eliminado y no rastreado. Luego" git reset --hard "reparó ese archivo y todos los otros archivos que estaban siendo reportados como "Los cambios no por etapas" (Antes de usar git rm, traté restablecimiento completo o ningún efecto) me encanta este tipo de sistemas de control de origen misterioso...
joeking

Ya sabes, elimina todo tu caché. En proyectos grandes puede perder mucho tiempo.
Ohar

Eso es brutal Podrías haber hecho lo mismo eliminando el directorio repo y volviendo a clonar.
ingyhere

44
Tenga en cuenta que está en Windows y que no distingue entre mayúsculas y minúsculas. Si también está trabajando con desarrolladores que utilizan sistemas de archivos que distinguen entre mayúsculas y minúsculas, como Macs o Linux, pueden estar comprometiendo etiquetas, ramas o incluso archivos en diferentes casos. En esa situación, su índice mostrará los archivos existentes que el SO sobrescribirá cuando se extraiga. La única forma de solucionarlo sería instituir una política de nomenclatura en su servidor Git (enlaces) o detectar errores de antemano.
ingyhere

97

Git no restablecerá los archivos que no están en el repositorio. Así que puedes:

$ git add .
$ git reset --hard

Esto organizará todos los cambios, lo que hará que Git esté al tanto de esos archivos y luego los restablecerá.

Si esto no funciona, puede intentar esconder y soltar los cambios:

$ git stash
$ git stash drop

44
Los archivos ya fueron rastreados. Lo intenté de todos modos y tampoco funciona. Debe haber algo realmente mal con mi repositorio, pero no tengo idea de qué. Para el git stash cosita, vea mi respuesta a Shahbaz.
Norswap

¿Qué sucede cuando haces un estado git?
YuriAlbuquerque

1
Pensé en una solución. Realice una confirmación y una nueva versión interactiva para borrar esa confirmación.
YuriAlbuquerque

Lo intenté en un momento, y funcionó, pero luego lo intenté una vez más y obtuve el sorprendente resultado descrito en la edición de mi respuesta.
Norswap

@YuriAlbuquerque, Git no entiende del todo POLA . ¿No se trata de git reset --hard" restablecer el área de preparación y el directorio de trabajo para que coincidan "? Si un archivo no está organizado, obviamente queremos eliminarlo cuando lo hagamos reset --hard.
Pacerier

71

Si usa Git para Windows, este es probablemente su problema

He tenido el mismo problema y el alijo, el restablecimiento completo, la limpieza o incluso todos seguían dejando cambios. Lo que resultó ser el problema fue el modo de archivo x que git no configuró correctamente. Este es un "problema conocido" con git para windows. Los cambios locales se muestran en el estado de gitk y git como modo antiguo 100755 modo nuevo 100644, sin ninguna diferencia real de archivos.

La solución es ignorar el modo de archivo:

git config core.filemode false

Más información aquí.


2
Esto funcionó cuando incluso cuando rm -rf *; git checkout HEAD .no lo hizo. ¡Uf!
forumulator

Funcionó para mí, mientras que el escondite / hard reset / rm .attributes fallaron.
kakyo

Esto también funcionó para mí cuando tuve problemas para trabajar con git repo en Linux que estaba alojado en una Mac
prmph

funcionó para mí, probé todo lo demás y sí, el modo antiguo frente al nuevo era el problema (noté que tenía un número diferente pero los archivos son los mismos)
Taehoon A Kim

Ahorrador de vida y tiempo.
Yogesh Patil

31

De acuerdo, he resuelto el problema.

Parecía que el .gitattributesarchivo, que contiene:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

hizo que los archivos del proyecto aparecieran sin etapas. No tengo idea de por qué es así, y realmente espero que alguien que conozca las formas de git nos dé una buena explicación.

Mi solución fue eliminar estos archivos, y para poner autocrlf = falsebajo [core]en .git/config.

Esto no equivale exactamente a lo mismo que la configuración anterior, ya que requiere que todos los desarrolladores tengan autocrlf = false. Me gustaría encontrar una solución mejor.

EDITAR:

Comenté las líneas incriminatorias, las descomenté y funcionó. ¡Qué ... ni siquiera ...!


1
Acabo de tener el mismo problema exacto y esta fue la única solución que funcionó. En mi caso, cambié de una rama de características a mi maestro y realicé algunos cambios nuevos desde arriba y comenzó a suceder para 2 archivos que fueron modificados. Parece que los archivos pueden haber cambiado de Unix a las terminaciones de línea de Windows que pueden tener algo que ver con eso. Sin embargo, no estoy seguro de cómo o por qué.
Steven Surowiec

+1 Mismo problema en Windows Git. Ya lo hice autocrlf = false. Me fusioné en los cambios desde el repositorio svn ascendente ( git svn fetch/ git merge git-svn) y me quedé con 1 archivo marcado como modificado. Lo extraño es que he tenido este problema antes y todo lo que tenía que hacer era verificar otra rama (con la -fbandera) y luego volver. Lo hice y funcionó, pero cuando cambié a una rama de características, ¡el "cambio" había vuelto! Su edición al final de la respuesta fue la solución. En mi caso, comenté / descomenté una línea en la parte superior de mi archivo .gitattributes:* text=auto !eol
Aaron Blenkush

1
Ese EDIT funcionó también para mí: comente las líneas .gitattributes, corra git status, descomente las líneas .gitattributes, corra git statusnuevamente
Ignitor

Esto se debe a que git está restableciendo esos archivos, luego aplica los finales de línea especificados en el .gitattributesnuevo. La git diffmuestra probablemente el famoso muro del / de la pared roja de color verde que es típica de las diferencias de fin de línea.
Dagrooms

22

Causa posible # 1 - Normalización de final de línea

Una situación en la que esto puede suceder es cuando el archivo en cuestión se registró en el repositorio sin la configuración correcta para las terminaciones de línea (1), lo que resultó en un archivo en el repositorio con terminaciones de línea incorrectas o terminaciones de línea mixtas. Para confirmar, verifique que git diffsolo muestre cambios en los finales de línea (estos pueden no ser visibles por defecto, intente git diff | cat -vver los retornos de carro como ^Mcaracteres literales ).

Posteriormente, alguien probablemente agregó .gitattributeso modificó la core.autocrlfconfiguración para normalizar las terminaciones de línea (2). Basado en la .gitattributesconfiguración global o, Git ha aplicado cambios locales a su copia de trabajo que aplican la línea que finaliza la normalización solicitada. Desafortunadamente, por alguna razón git reset --hardno deshace estos cambios de normalización de línea.

Solución

Las soluciones en las que se restablecen las terminaciones de línea locales no resolverán el problema. Cada vez que git "ve" el archivo, intentará volver a aplicar la normalización, dando como resultado el mismo problema.

La mejor opción es dejar que git aplique la normalización que desea mediante la normalización de todas las terminaciones de línea en el repositorio para que coincida con .gitattributes, y confirmar esos cambios; consulte Intentar arreglar las terminaciones de línea con git filter-branch, pero no tener suerte .

Si realmente desea intentar y revertir los cambios en el archivo manualmente, entonces la solución más fácil parece ser borrar los archivos modificados, y luego decirle a git que los restaure, aunque noto que esta solución no parece funcionar consistentemente al 100% el tiempo ( ADVERTENCIA: ¡NO ejecute esto si sus archivos modificados tienen cambios que no sean terminaciones de línea!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Tenga en cuenta que, a menos que normalice las terminaciones de línea en el repositorio en algún momento, seguirá encontrándose con este problema.

Causa posible # 2 - Insensibilidad de mayúsculas y minúsculas

La segunda causa posible es la insensibilidad a mayúsculas y minúsculas en Windows o Mac OS / X. Por ejemplo, supongamos que existe una ruta como la siguiente en el repositorio:

/foo/bar

Ahora alguien en Linux compromete archivos /foo/Bar(probablemente debido a una herramienta de compilación o algo que creó ese directorio) y empuja. En Linux, esto es en realidad ahora dos directorios separados:

/foo/bar/fileA
/foo/Bar/fileA

Verificar este repositorio en Windows o Mac puede resultar en modificaciones fileAque no se pueden restablecer, porque en cada restablecimiento, git en Windows se desprotege /foo/bar/fileA, y luego porque Windows no distingue entre mayúsculas y minúsculas, sobrescribe el contenido de fileAcon /foo/Bar/fileA, lo que hace que se "modifiquen".

Otro caso puede ser un archivo (s) individual que existe en el repositorio, que cuando se desprotege en un sistema de archivos que no distingue entre mayúsculas y minúsculas, se superpondría. Por ejemplo:

/foo/bar/fileA
/foo/bar/filea

Puede haber otras situaciones similares que podrían causar tales problemas.

git en sistemas de archivos que no distinguen entre mayúsculas y minúsculas realmente debería detectar esta situación y mostrar un mensaje de advertencia útil, pero actualmente no lo hace (esto puede cambiar en el futuro - vea esta discusión y los parches propuestos relacionados en la lista de correo de git.git).

Solución

La solución es alinear el caso de los archivos en el índice git y el caso en el sistema de archivos de Windows. Esto se puede hacer en Linux que mostrará el verdadero estado de las cosas, O en Windows con la muy útil utilidad de código abierto Git-Unite . Git-Unite aplicará los cambios de caso necesarios al índice git, que luego se puede confirmar en el repositorio.

(1) Probablemente fue alguien que usó Windows, sin ninguna .gitattributesdefinición para el archivo en cuestión, y que utilizó la configuración global predeterminada para la core.autocrlfcual es false(ver (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/


Maldito hijo, tomó todo el camino hasta este. Tuve que comprometerme después de la primera línea, pero finalmente pude pagar master. Eso no fue divertido.
Tim Lieberman el

16

Si otras respuestas no funcionan, intente agregar los archivos y luego reinicie

$ git add -A
$ git reset --hard

En mi caso, esto ayudó cuando había un montón de archivos vacíos que Git estaba rastreando.


Esto funciona. Acabo de usar en $ git add .lugar de$ git add -A
Bjarne Gerhardt-Pedersen

8

Otra causa de esto podría ser sistemas de archivos que no distinguen entre mayúsculas y minúsculas . Si tiene varias carpetas en su repositorio en el mismo nivel cuyos nombres solo difieren según el caso, esto lo afectará. Explore el repositorio de origen utilizando su interfaz web (por ejemplo, GitHub o VSTS) para asegurarse.

Para más información: https://stackoverflow.com/a/2016426/67824


Para encontrar los nombres de dichos archivos, ejecutegit ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d
Diomidis Spinellis


5

Ninguno de estos métodos funcionó para mí, la única solución fue destruir el repositorio completo y volver a clonarlo. Esto incluye guardar, restablecer, agregar y restablecer, configuraciones de clrf, mayúsculas y minúsculas, etc. Suspiro.


Actualización, resultó que mi sistema de archivos de mayúsculas y minúsculas montado no era realmente sensible a mayúsculas y minúsculas. Después de arreglar que este problema se podía solucionar usando las técnicas mencionadas anteriormente.
John Hunt, el

4

Ejecute el comando de limpieza :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

3
Lamentablemente, esto no resuelve los problemas relacionados con los finales de línea.
Christopher Schneider

Esto es lo único que resuelve mi problema, sea cual sea mi problema. No tenía .gitattributesarchivos y las terminaciones de línea no eran un problema ya que estoy en una caja de Linux y todos los desarrolladores y nuestro servidor son Linux.
Samuel Neff

4

Comprueba tu .gitattributes.

En mi caso tengo *.js text eol=lfen ella y la opción git core.autocrlfestaba true.

Me lleva a la situación en la que git convierte automáticamente las terminaciones de línea de mis archivos y me impide arreglarlo e incluso git reset --hard HEADno hizo nada.

Lo solucioné comentando *.js text eol=lfen mi .gitattributesy lo descomenté después.

Parece que solo es magia.


Esto fue todo para mí, actualizar mi proyecto presentado *.bat text eol=crlfa mi proyecto.
Leo

1

Llegué a un problema similar que también involucraba .gitattributes, pero para mi caso involucraba el LFS de GitHub. Si bien este no es exactamente el escenario del OP, creo que brinda una oportunidad para ilustrar lo que hace el .gitattributesarchivo y por qué puede conducir a cambios no organizados en forma de diferencias "fantasmas".

En mi caso, un archivo ya estaba en mi repositorio, como desde el principio de los tiempos. En una confirmación reciente, agregué una nueva git-lfs trackregla que usaba un patrón que, en retrospectiva, era demasiado amplio y que coincidía con este archivo antiguo. Sé que no quería cambiar este archivo; Sé que no cambié el archivo, pero ahora estaba en mis cambios no organizados y ninguna cantidad de pagos o reinicios duros en ese archivo iba a solucionarlo. ¿Por qué?

La extensión GitHub LFS funciona principalmente mediante el aprovechamiento de los ganchos que gitproporcionan acceso a través del .gitattributesarchivo. En general, las entradas en .gitattributesespecifican cómo se deben procesar los archivos coincidentes. En el caso del OP, se refería a la normalización de las terminaciones de línea; en el mío, era si dejar que LFS maneje el almacenamiento de archivos. En cualquier caso, el archivo real que se gitve al calcular un git diffarchivo no coincide con el archivo que ve cuando lo inspecciona. Por lo tanto, si cambia la forma en que se procesa un archivo a través del .gitattributespatrón que lo coincide, aparecerá como cambios no escalonados en el informe de estado, incluso si realmente no hay ningún cambio en el archivo.

Todo lo dicho, mi "respuesta" a la pregunta es que si el cambio en el .gitattributesarchivo es algo que desea hacer, realmente debería simplemente agregar los cambios y seguir adelante. Si no es así, modifíquelo .gitattributespara representar mejor lo que quiere hacer.

Referencias

  1. Especificación de GitHub LFS : excelente descripción de cómo se conectan a las llamadas cleany smudgefunciones para reemplazar su archivo en los gitobjetos con un simple archivo de texto con un hash.

  2. Documentación de gitattributes : todos los detalles sobre lo que está disponible para personalizar cómo gitprocesa sus documentos.


0

Yo tuve el mismo problema. Lo hice git reset --hard HEADpero aún así cada vez que lo hicegit status estaba viendo algunos archivos modificados.

Mi solución fue relativamente simple. Acabo de cerrar mi IDE (aquí era Xcode) y cerrar mi línea de comando (aquí era terminal en mi Mac OS) e intenté nuevamente y funcionó.

Sin embargo, nunca pude encontrar lo que originó el problema.


0

Creo que hay un problema con git para Windows en el que git escribe aleatoriamente las terminaciones de línea incorrectas al finalizar la compra y la única solución es verificar alguna otra rama y obligar a git a ignorar los cambios. Luego revisa la rama en la que realmente quieres trabajar.

git checkout master -f
git checkout <your branch>

Tenga en cuenta que esto descartará cualquier cambio que haya hecho intencionalmente, así que solo haga esto si tiene este problema inmediatamente después del pago.

Editar: podría haber tenido suerte la primera vez. Resulta que me volví a morder después de cambiar de rama. Resultó que los archivos que Git informaba como modificados después de cambiar las ramas estaban cambiando. (Aparentemente porque git no estaba aplicando consistentemente la línea CRLF que terminaba en los archivos correctamente).

Actualicé al último git para Windows y espero que el problema haya desaparecido.


0

Problema similar, aunque estoy seguro solo en la superficie. De todos modos, puede ayudar a alguien: lo que hice (FWIW, en SourceTree): guardé el archivo no confirmado, luego hice un restablecimiento completo.


0

Como han señalado otras respuestas, el problema se debe a la corrección automática de final de línea. Encontré este problema con los archivos * .svg. Utilicé el archivo svg para los iconos en mi proyecto.

Para resolver este problema, le digo a git que los archivos svg deben tratarse como binarios en lugar de texto agregando la siguiente línea a .gitattributes

* .svg binario


0

En una situación similar. Como resultado de muchos años de tormento con muchos programadores que pudieron insertar diferentes codificaciones de los extremos de las líneas (. Asp , .js, .css ... no la esencia) en un solo archivo. Hace algún tiempo rechazó .gitattributes. Configuraciones para repositorio izquierda autorclf = trueysafecrlf = warn .

El último problema surgió al sincronizar desde el archivo con diferentes extremos de líneas. Después de copiar del archivo, en el estado de git muchos archivos se cambian con la nota

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Consejos de Cómo normalizar las terminaciones de línea de árbol de trabajo en Git? ayudado

git add -u


0

Otra posibilidad que encontré fue que uno de los paquetes en el repositorio terminaba con un HEAD separado. Si ninguna de las respuestas aquí ayuda y encuentra un mensaje de estado de git como este, podría tener el mismo problema:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

Entrar en la path/to/packagecarpeta a git statusdebería producir el siguiente resultado:

HEAD detached at 7515f05

Y el siguiente comando debería solucionar el problema, donde masterdebería ser reemplazado por su sucursal local:

git checkout master

Y recibirá un mensaje de que su sucursal local tendrá algunas cantidades de confirmaciones detrás de la sucursal remota. git pully deberías estar fuera del bosque!


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.