remoto - ignorar cambios git

Cambios sin etapas dejados después de git reset--hard (18)

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 fue registrado en el repositorio sin la configuración correcta para los finales de línea (1) que resultó en un archivo en el repositorio con los finales de línea incorrectos o los finales de línea mixtos. Para confirmar, verifique que git diff muestre solo los cambios en los finales de línea (es posible que estos no sean visibles de manera predeterminada, intente con git diff | cat -v para ver los retornos de carro como caracteres ^M sentido literal).

Posteriormente, alguien probablemente agregó un .gitattributes o modificó la configuración core.autocrlf para normalizar los finales de línea (2). Sobre la base de los .gitattributes o la configuración global, Git ha aplicado cambios locales a su copia de trabajo que aplican la normalización de la línea solicitada. Desafortunadamente, por alguna razón, git reset --hard no deshace estos cambios de normalización de línea.

Solución

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

La mejor opción es dejar que git aplique la normalización a la que quiere normalizando todos los finales de línea en el repositorio para que coincidan con los .gitattributes , y .gitattributes esos cambios. Consulte Intentar corregir finales de línea con git filter-branch, pero no tener suerte

Si realmente desea probar 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 observo que esta solución no parece funcionar de manera consistente. la hora ( ADVERTENCIA: NO ejecute esto si sus archivos modificados tienen cambios distintos a los finales de línea):

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

Tenga en cuenta que, a menos que normalice los finales de línea en el repositorio en algún momento, continuará encontrando este problema.

Causa posible # 2 - Insensibilidad al caso

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

/foo/bar

Ahora alguien en Linux confirma los archivos en /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

La comprobación de este repositorio en Windows o Mac puede resultar en un fileA modificado A que no se puede restablecer, porque en cada reinicio, git en Windows extrae /foo/bar/fileA , y luego porque Windows no distingue entre mayúsculas y minúsculas, sobrescribe el contenido del fileA con /foo/Bar/fileA , resultando en que se "modifiquen".

Otro caso puede ser un archivo (s) individual (es) que existe en el repositorio, que cuando se extrae 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 los sistemas de archivos que no distinguen entre mayúsculas y minúsculas debería detectar realmente esta situación y mostrar un mensaje de advertencia útil, pero actualmente no lo hace (esto puede cambiar en el futuro; consulte 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 utilidad de código abierto muy útil Git-Unite . Git-Unite aplicará los cambios de caso necesarios al índice de git, que luego se puede confirmar en el repositorio.

(1) Lo más probable es que alguien usara Windows, sin ninguna definición de .gitattributes para el archivo en cuestión, y que usara la configuración global predeterminada para core.autocrlf que es false (ver (2)).

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

El título lo dice todo.

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

También he intentado git reset . , git checkout -- . y git checkout-index -f -a , en vano.

Entonces, ¿cómo puedo deshacerme de esos cambios sin etapas?

Esto parece golpear sólo los archivos de proyecto de Visual Studio. Extraño. Vea este pegamento: 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, autocrlf se establece en falso en mi .gitconfig global. ¿Podría ser de alguna manera relevante?

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.

Si usas Git para Windows, este es probablemente tu problema

He tenido el mismo problema y el alijo, el restablecimiento completo, la limpieza o incluso todos ellos seguían dejando atrás los cambios. Lo que resultó ser el problema fue el modo de archivo x que no fue configurado correctamente por git. Este es un "problema conocido" con git para windows. Los cambios locales se muestran en gitk y git status como modo antiguo 100755 modo nuevo 100644, sin diferencias reales de archivos.

La solución es ignorar el modo de archivo:

git config core.filemode false

Más información aquí

¡¡¡RESUELTO!!!

He resuelto este problema usando los siguientes stpes

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

git rm --cached -r .

2) Reescriba el índice de Git para recoger todos los nuevos finales de línea.

git reset --hard

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

Como han señalado otras respuestas, el problema se debe a la corrección automática de fin de línea. Encontré este problema con los archivos * .svg. Usé 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

Compruebe sus .gitattributes .

En mi caso tengo *.js text eol=lf y git option core.autocrlf era true .

Me lleva a la situación en la que git autoconvierte los finales de la línea de mis archivos y me impide corregirlos e incluso git reset --hard HEAD no hizo nada.

Lo .gitattributes comentando *.js text eol=lf en mis .gitattributes y lo descomenté después.

Parece que es sólo magia.

Creo que hay un problema con git para Windows donde git escribe aleatoriamente los finales de línea incorrectos en el proceso de pago y la única solución alternativa es el proceso de pago en otra rama y obliga 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 de finalizar la compra.

Edit: podría haber tenido suerte la primera vez. Resulta que recibí un poco de nuevo después de cambiar de ramas. Resultó que los archivos que git estaba informando como modificados después de cambiar las sucursales estaban cambiando. (Aparentemente porque git no estaba aplicando la línea CRLF de manera consistente a los archivos correctamente).

He actualizado a la última versión de git para Windows y espero que el problema se haya ido.

Ejecutar comando limpio :

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

En una situación similar. Como resultado de muchos años de tormento con muchos programadores que fueron capaces de rellenar diferentes codificaciones de los extremos de las líneas ( .asp , .js, .css ... no la esencia) en un archivo. Hace un tiempo rechazó .gitattributes. Configuraciones para repo left autorclf = true y safecrlf = warn .

El último problema surgió al sincronizar desde el archivo con diferentes extremos de líneas. Después de copiar desde el 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 sobre cómo normalizar las terminaciones de líneas de árboles de trabajo en Git? ayudado

git add -u

Encontré un problema similar que también involucraba .gitattributes , pero en mi caso estaba relacionado con 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 archivo .gitattributes y por qué puede llevar a cambios sin etapas en la 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 regla de git-lfs track usando un patrón que era en retrospectiva un poco demasiado amplio, y terminé haciendo coincidir este archivo antiguo. Sé que no quería cambiar este archivo; Sé que no cambié el archivo, pero ahora estaba en mis cambios no programados y ninguna cantidad de comprobaciones o reinicios en ese archivo lo arreglaría. ¿Por qué?

La extensión GitHub LFS funciona principalmente mediante el aprovechamiento de los ganchos a los que git proporciona acceso a través del archivo .gitattributes . En general, las entradas en .gitattributes especifican cómo deben procesarse los archivos coincidentes. En el caso del OP, se preocupaba por normalizar los finales de línea; en la mía, era si permitir que LFS maneje el almacenamiento de archivos. En cualquier caso, el archivo que ve git al calcular un git diff no coincide con el archivo que se ve al inspeccionar el archivo. Por lo tanto, si cambia la forma en que se procesa un archivo a través del patrón .gitattributes que lo coincide, se mostrarán como cambios sin etapas en el informe de estado, incluso si realmente no hay cambios en el archivo.

Dicho todo esto, mi "respuesta" a la pregunta es que si el cambio en el archivo .gitattributes es algo que usted desea hacer, debería agregar los cambios y seguir adelante. Si no es así, modifique los .gitattributes de .gitattributes para representar mejor lo que quiere hacer.

Referencias

Especificación de GitHub LFS : una gran descripción de cómo se enganchan en las llamadas de la función de clean y smudge para reemplazar su archivo en los objetos git con un archivo de texto simple con un hash.
Documentación de gitattributes : todos los detalles sobre lo que está disponible para personalizar cómo git procesa sus documentos.

Está bien, he resuelto el tipo de problema.

Parecía que el archivo .gitattributes , que contiene:

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

Hizo que los archivos del proyecto aparecieran sin organizar. No tengo ni idea de por qué, 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 agregar autocrlf = false en [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 mejor solución.

EDITAR:

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

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

$ git add . $ git reset --hard

Esto hará que se realicen 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 eliminar sus cambios:

$ git stash $ git stash drop

Ninguno de estos métodos funcionó para mí, la única solución fue atacar todo el repositorio y volver a clonarlo. Esto incluye el ocultamiento, restablecimiento, adición luego restablecimiento, ajustes de clrf, sensibilidad a las mayúsculas, etc. Suspiro ..

Otra causa para 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, se verá afectado por esto. Explore el repositorio de origen utilizando su interfaz web (por ejemplo, GitHub o VSTS) para asegurarse.

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

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

Puedes stash tus cambios y luego dejar caer el alijo:

git stash git stash drop

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

Pude resolver el problema simplemente ejecutando

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

Yo tuve el mismo problema. Hice git reset --hard HEAD pero cada vez que lo hacía, estaba viendo algunos archivos modificados.

Mi solución fue relativamente simple. Acabo de cerrar mi IDE (aquí estaba Xcode), cerré mi línea de comandos (aquí era terminal en mi Mac OS) y lo intenté de nuevo y funcionó.

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