tipos - revertir cambios en un archivo git
Archivos que se muestran como modificados directamente después de git clone (16)
Copié mi repositorio local a otra carpeta y aparecieron un montón de archivos modificados. Mi solución fue: escondí los archivos modificados y eliminé el alijo . El repositorio quedó limpio.
Estoy teniendo un problema con un repositorio en este momento, y aunque mi git-fu es generalmente bueno, parece que no puedo resolver este problema.
Cuando cloné este repositorio, luego cd en el repositorio, git-status muestra varios archivos 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.
He intentado git checkout -- . Muchas veces pero parece no hacer nada.
Cualquier ayuda / ideas serían apreciadas grandemente
Actualización 1: Estoy en un mac y no hay submódulos en el propio repositorio.
Actualización 2: el sistema de archivos es el sistema de archivos "Journaled HFS +" en el mac, y no distingue entre mayúsculas y minúsculas. Los archivos son de una línea y aproximadamente 79K cada uno (sí, has oído bien), por lo que mirar git diff no es particularmente útil. He escuchado acerca de hacer git config --global core.trustctime false que podría ayudar, algo que intentaré cuando regrese a la computadora con el repositorio en él.
Actualización 3: cambio de detalles del sistema de archivos con hechos! y probé el truco git config --global core.trustctime false que no funcionó muy bien.
Descubrí que git estaba tratando mis archivos (.psd en este caso) como texto. Estableciéndolo en un tipo binario en los .gitattributes lo resolvió.
*.psd binary
Editar archivo llamado: sudo gedit .git/config sudo vim .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]: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 = true en filemode = false
El mismo problema para mí. Pude ver varias imágenes con el mismo nombre como "textField.png" y "textfield.png" en el repositorio de Git remoto, 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 yo 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 eliminara las versiones redundantes de los archivos con mayúsculas, luego confirmara y presionara el control remoto.
Luego corrí 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 config
git config core.ignorecase = true
o
# Global Git config
git config --global core.ignorecase = true
El problema también puede surgir de diferentes permisos de archivos , como fue mi caso:
Nuevo repositorio clonado (Windows, Cygwin):
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
Repositorio remoto desnudo (Linux):
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
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.
Entiendo. Todos los demás desarrolladores están en Ubuntu (creo), y por lo tanto tienen sistemas de archivos que distinguen entre mayúsculas y minúsculas. Yo, sin embargo, no (como estoy en un mac). De hecho, todos los archivos tenían gemelos en minúscula cuando los eché un vistazo usando git ls-tree HEAD <path> .
Haré que uno de ellos lo resuelva.
Estaba teniendo un problema similar y encontré esta pregunta.
Estaba tratando de hacer una rebase interactiva, pero decía que había algunos archivos modificados, por lo que no me dejaba hacerlo ahora. Intenté TODO para volver a un repo 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! Repo limpio. Problema resuelto. Luego simplemente tuve que abandonar el último compromiso cuando hice mi rebase -i y, finalmente, todo estaba limpio otra vez. ¡Extraño!
Pero estoy agregando esta solución aquí para que tal vez, si alguna vez me encuentro con esto, lo vea y lo pruebe. Gracias: D
Para las nuevas versiones de macOS, esto puede deberse a 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. Era solo algunos datos serializados, pero macOS trata a todos los archivos * .app como una aplicación y, como el usuario no descargó este archivo, el sistema lo consideró inseguro y agregó el com.apple.quarantine archivo com.apple.quarantine , lo que garantiza que el archivo pueda no ser ejecutado
Pero establecer este atributo en el archivo también estaba cambiando el archivo y, por lo tanto, apareció en el conjunto de cambios de git sin ninguna forma de revertirlo.
Puede verificar si tiene el mismo problema ejecutando $ xattr file.app
La solución es bastante simple, siempre y cuando no tenga que trabajar con el archivo. Simplemente añada *.app binary a sus .gitattributes
Por favor, 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
Quería agregar una respuesta más dirigida sobre "Por qué" esto sucede, porque ya hay una buena respuesta sobre cómo solucionarlo.
Por lo tanto, .gitattributes tiene una configuración * text=auto , que causa este problema.
En mi caso, los archivos en la rama maestra de GitHub tenían /r/n finales. He marcado la configuración en el repositorio para registrarme con /n finales. Aunque no sé qué comprueba Git. Se supone que verifique con terminaciones nativas en mi caja de Linux ( /n ), pero creo que verificó el archivo con terminaciones /r/n . Git se queja porque ve los finales /r/n que estaban en el repositorio y me advierte que verificará las configuraciones /n . Por lo tanto, los archivos están "para ser modificados".
Esa es mi comprensión por ahora.
Supongo que está utilizando Windows. Esa página github que has enlazado tiene los detalles al revés. El problema es que los finales de línea CRLF ya se han comprometido con el repositorio y debido a que tiene core.autocrlf establecido en true o input , git quiere convertir los finales de línea a LF, por lo que el git status muestra que todos los archivos cambian.
Si este es un repositorio al que solo desea acceder, pero no tiene participación, 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 realizar cambios. Es posible que desee solucionar el problema haciendo un compromiso que cambie todos los finales de línea en el repositorio para usar LF en lugar de CRLF y luego tomar medidas para evitar que vuelva a suceder en el futuro.
Lo siguiente se toma directamente de la página del 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 alguno de los archivos que no deberían normalizarse se muestra en el estado de git, desactive su atributo de texto antes de ejecutar git add -u .
manual.pdf -text
A la inversa, los archivos de texto que git no detecta pueden tener la normalización habilitada manualmente.
weirdchars.txt text
También acabo de tener el mismo problema. En mi caso cloné el repositorio y faltaron inmediatamente algunos archivos.
Esto fue causado por la ruta al archivo y el nombre de archivo es demasiado largo para Windows. Para resolverlo, clone el repositorio lo más cerca posible de la raíz de hdd para reducir la longitud de la ruta al archivo, por ejemplo, clónelo en C: / A / GitRepo en lugar de C: / Users Documents / yyy / Desktop / GitRepo
Tuve el mismo problema en la Mac después de clonar un repositorio, supondría que se han cambiado todos los archivos.
Después de ejecutar la entrada git config --global core.autocrlf input , seguía marcando todos los archivos como modificados. Después de buscar una solución, .gitattributes archivo .gitattributes en el directorio de inicio que tenía lo siguiente.
* text=auto
Lo comenté y, de ahora en adelante, cualquier otro repositorio clonado funciona bien. Espero que esto ayude a alguien por ahí.
Yo tuve el mismo problema. También con una Mac. Mirando el repositorio en una máquina linux noté que tenía dos archivos:
geoip.dat y GeoIP.dat
Se eliminó el desaprobado en la máquina de Linux y se clonó el repositorio de nuevo en el mac. No pude extraer, cometer, esconder o sacar de mi copia del repositorio cuando había duplicados.
git config core.fileMode false
resuelto este problema en mi caso
https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html
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 true, excepto que git-clone (1) o git-init (1) sondearán y establecerán core.fileMode falso si es apropiado cuando se crea el repositorio.