Archivos que se muestran como modificados directamente después de un clon de Git

Tengo un problema con un repositorio en este momento, y aunque mi Git-fu suele ser bueno, parece que no puedo resolver este problema.

Cuando clono este repositorio, luego cden el repositorio, git statusmuestra varios archivos como modificados. Nota: No he abierto el repositorio en ningún editor ni nada.

Intenté seguir esta guía: http://help.github.com/dealing-with-lineendings/ , pero esto no ayudó en absoluto con mi problema.

Lo he intentado git checkout -- .muchas veces, pero parece que no hace nada.

Estoy en una Mac y no hay submódulos en el repositorio.

El sistema de archivos es el sistema de archivos "Journaled HFS +" en Mac y no distingue entre mayúsculas y minúsculas. Los archivos son de una línea y tienen aproximadamente 79 KB cada uno (sí, lo escuchó bien), por lo que mirar git diffno es particularmente útil. He escuchado sobre hacer lo git config --global core.trustctime falseque podría ayudar, lo que intentaré cuando regrese a la computadora con el repositorio.

¡Cambié los detalles del sistema de archivos con hechos! Y probé el git config --global core.trustctime falsetruco que no funcionó muy bien.

Tuve el mismo problema en la Mac después de clonar un repositorio. Asumiría que todos los archivos habían sido cambiados.

Después de ejecutarse git config --global core.autocrlf input, seguía marcando todos los archivos como modificados. Después de buscar una solución, encontré el .gitattributesarchivo en el directorio de inicio que tenía lo siguiente.

* text=auto

Lo comenté y cualquier otro repositorio clonado a partir de ahora estaba funcionando bien.

Lo tengo. Todos los otros desarrolladores están en Ubuntu (creo) y, por lo tanto, tienen sistemas de archivos sensibles a mayúsculas y minúsculas. Yo, sin embargo, no (como estoy en una Mac). De hecho, todos los archivos tenían gemelos en minúsculas cuando los miré usando git ls-tree HEAD <path>.

Conseguiré uno de ellos para resolverlo.

git config core.fileMode false

resuelto este problema en mi caso

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

Si es falso, las diferencias de bits ejecutables entre el índice y el árbol de trabajo se ignoran; útil en sistemas de archivos rotos como FAT. Ver git-update-index (1).

El valor predeterminado es verdadero, excepto que git-clone (1) o git-init (1) probarán y establecerán core.fileMode false si es apropiado cuando se crea el repositorio.

Supongo que estás usando Windows. Esa página de GitHub a la que se vinculó tiene los detalles al revés. El problema es que las terminaciones de línea CR + LF ya se han comprometido con el repositorio y debido a que tiene core.autocrlf configurado como verdadero o de entrada , Git quiere convertir las terminaciones de línea a LF, por lo git statusque muestra que cada archivo ha cambiado.

Si este es un repositorio al que solo desea acceder, pero no está involucrado, puede ejecutar el siguiente comando para simplemente ocultar el problema sin resolverlo realmente.

git config core.autocrlf false

Si este es un repositorio en el que participará activamente y puede enviar cambios. Es posible que desee solucionar el problema haciendo una confirmación que cambie todas las terminaciones de línea en el repositorio para usar LF en lugar de CR + LF y luego tome medidas para evitar que vuelva a suceder en el futuro.

Lo siguiente se toma directamente de la página de manual de gitattributes y se debe realizar desde un directorio de trabajo limpio.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Si aparecen archivos que no deberían normalizarse git status, desarme su atributo de texto antes de ejecutarlo git add -u.

manual.pdf      -text

Por el contrario, los archivos de texto que Git no detecta pueden tener la normalización habilitada manualmente.

weirdchars.txt  text

Ejecute los siguientes comandos. Eso podría resolver el problema.

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

En Visual Studio, si está utilizando Git, puede generar automáticamente los archivos .gitignore y .gitattributes. El archivo .getattributes generado automáticamente tiene la siguiente línea:

* text=auto

Esta línea está cerca de la parte superior del archivo. Solo necesitábamos comentar la línea agregando un # al frente. Después de hacer eso, las cosas funcionaron como se esperaba.

El problema también podría surgir de diferentes permisos de archivos , como fue mi caso:

Nuevo repositorio clonado (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Depósito remoto desnudo (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Quería agregar una respuesta más dirigida a "Por qué" esto sucede, porque ya hay una buena respuesta sobre cómo solucionarlo.

Entonces, .gitattributestiene una * text=autoconfiguración, lo que causa este problema.

En mi caso, los archivos en la rama maestra de GitHub tenían \r\nterminaciones. He marcado la configuración en el repositorio para registrarme con \nterminaciones. Sin embargo, no sé lo que Git comprueba. Se supone que debe verificar con terminaciones nativas en mi caja de Linux ( \n), pero supongo que revisó el archivo con \r\nterminaciones. Git se queja porque ve las \r\nterminaciones desprotegidas que estaban en el repositorio y me advierte que verificará la \nconfiguración. Por lo tanto, los archivos deben "modificarse".

Esa es mi comprensión por ahora.

Yo tuve el mismo problema. También con una Mac. Al mirar el repositorio en una máquina Linux, noté que tenía dos archivos:

geoip.dat y GeoIP.dat

Eliminé el obsoleto en la máquina Linux y cloné el repositorio nuevamente en la Mac. No pude extraer, comprometer, esconder o extraer de mi copia del repositorio cuando había duplicados.

El mismo problema para mí. Pude ver varias imágenes con el mismo nombre, como "textField.png" y "textfield.png" en el repositorio remoto de Git, pero no en mi repositorio local. Solo pude ver "textField.png" que no se usó en el código del proyecto.

Resulta que la mayoría de mis colegas están en Ubuntu usando el sistema de archivos ext4, mientras que estoy en una Mac usando APFS.

Gracias a la respuesta de Sam Elliott , la solución fue bastante simple. Primero le pedí a un colega en Ubuntu que borrara las versiones de archivos redundantes con mayúsculas, luego confirme y presione el control remoto.

Luego ejecuté lo siguiente:

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Finalmente, decidimos que cada desarrollador debería cambiar su configuración de Git para evitar que esto vuelva a suceder:

# Local Git configuration
git config core.ignorecase = true

o

# Global Git configuration
git config --global core.ignorecase = true

También tuve el mismo problema. En mi caso cloné el repositorio y algunos archivos desaparecieron de inmediato.

Esto fue causado por la ruta al archivo y el nombre de archivo demasiado largo para Windows. Para resolverlo, clone el repositorio lo más cerca posible de la raíz del disco duro para reducir la longitud de la ruta al archivo. Por ejemplo, clónelo en C:\A\GitRepolugar de C:\Users Documents\yyy\Desktop\GitRepo.

Edite el archivo llamado .git/config:

sudo gedit .git/config

O:

sudo vim .git/config

Contenido

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

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

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

Cambiar filemode=truea filemode = false.

Para las nuevas versiones de macOS, esto puede ser causado por una característica de seguridad del sistema operativo.

En el repositorio en el que estaba trabajando, había un archivo binario que tenía * .app como tipo de archivo.

Eran solo algunos datos serializados, pero macOS trata todos los archivos * .app como una aplicación y como este archivo no fue descargado por el usuario, el sistema lo consideró inseguro y agregó el com.apple.quarantineatributo de archivo que asegura que el archivo no se pueda ejecutar.

Pero establecer este atributo en el archivo también estaba cambiando el archivo y, por lo tanto, apareció en el conjunto de cambios Git sin ninguna forma de revertirlo.

Puede verificar si tiene el mismo problema ejecutando $ xattr file.app.

La solución es bastante simple, siempre que no tenga que trabajar con el archivo. Solo agrégalo *.app binarya tu .gitattributes.

Copié mi repositorio local a otra carpeta y apareció un montón de archivos modificados. Mi solución fue: escondí los archivos modificados y eliminé el alijo . El repositorio se volvió limpio.

Descubrí que Git estaba tratando mis archivos (.psd en este caso) como texto. Ajustándolo a un tipo binario en .gitattributes lo resolvió.

*.psd binary

Estaba tratando de hacer un rebase interactivo, pero afirmaba que había algunos archivos modificados, por lo que no me permitía hacerlo ahora. Intenté todo para volver a un repositorio limpio, pero nada funcionó. Ninguna de las otras respuestas ayudó. Pero esto finalmente funcionó ...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

¡Auge! Depósito limpio. Problema resuelto. Luego tuve que soltar el último commit cuando hice mi rebase -iy finalmente todo estaba limpio nuevamente. ¡Extraño!

En caso de que ayude a alguien más, puede haber otra causa para este problema: diferentes versiones de Git. Estaba usando la versión predeterminada instalada de Git en un cuadro de Ubuntu 18.04 (Bionic Beaver) y todo funcionaba bien, pero cuando intentaba clonar el repositorio usando Git en Ubuntu 16.04, algunos archivos aparecían modificados.

Ninguna de las otras respuestas aquí solucionó mi problema, pero actualizar las versiones de Git para que coincidan en ambos sistemas solucionó el problema.