¿Cómo elimino los archivos que dicen "modo antiguo 100755 nuevo modo 100644" de cambios no realizados en Git?

Question

Por alguna razón, cuando inicialmente hice una extracción del repositorio para un proyecto mío git, obtuve un montón de archivos en mi copia de trabajo que no tienen cambios perceptibles en ellos, pero siguen apareciendo en mi área unstaged changes .

Estoy usando Git Gui en Windows XP, y cuando voy a ver el archivo para ver qué ha cambiado. Todo lo que veo es:

old mode 100755 
new mode 100644 

¿Alguien sabe lo que esto significa?

¿Cómo puedo obtener estos archivos de mi lista de cambios sin registrar? (Es muy molesto tener que ir a través de cientos de archivos, solo para seleccionar los archivos que he editado recientemente y quiero comprometer).

Answer 1

que se parece a UNIX modos de permisos de archivo para mí (= 755rwxr-xr-x, 644 = rw-r--r--) - el modo de edad incluyó el indicador x (ejecutable) +, el nuevo modo no lo hace.

This msysgit issue's replies sugiere establecer core.filemode a falsa con el fin de deshacerse de la cuestión:

git config core.filemode false 

Answer 2

Usted podría intentar restablecer git CABEZA --hard para restablecer el repositorio al estado predeterminado esperado.

Answer 3

Configurar core.filemode en false funciona. Pero se aseguraría de que las configuraciones en ~/.gitconfig no sean anuladas por aquellos en .git/config.

Answer 4

Parece que ha cambiado algunos permisos del directorio. Hice los siguientes pasos para restaurarlo.

$ git diff > backup-diff.txt    ### in case you have some other code changes 

$ git checkout . 

Answer 5

Tenía el único archivo problemático con los permisos cambiados. Para volver a enrollarlo individualmente, lo eliminé manualmente con rm <file> y luego hice un checkout para extraer una nueva copia.

Afortunadamente aún no lo había organizado.

Si tuviera que podría haber corrido git reset -- <file> antes de ejecutar git checkout -- <file>

Answer 6

Esto sucede cuando se tire y todos los archivos eran ejecutable en el repositorio remoto. Hacerlos ejecutables de nuevo volverá a poner todo en orden.

chmod +x <yourfile> //For one file 
chmod +x folder/* // For files in a folder 

Es posible que tenga que hacer:

chmod -x <file> // Removes execute bit 

en cambio, para los archivos que no se ha establecido como ejecutable y que fue cambiado debido a la operación anterior. Hay una mejor manera de hacerlo, pero esto es solo una solución muy rápida y sucia.

Answer 7

He encontrado este problema al copiar un git repo con archivos de trabajo de un disco duro viejo un par de veces. El problema surge del hecho de que el propietario y los permisos cambiaron de la unidad/máquina anterior a la nueva.El largo y corto de él es, ejecute los siguientes comandos para enderezar las cosas (thanks to this superuser answer):

sudo chmod -R -x . # remove the executable bit from all files 

El ex comando realmente resolver las diferencias que informaron git diff, pero habrá revocar su capacidad de enumerar los directorios, por lo que ls ./ falla con ls: .: Permission denied. Para corregir esto:

sudo chmod -R +X . # add the executable bit only for directories 

La mala noticia es que si usted tiene los archivos que desea mantener ejecutable, tales como .sh guiones, tendrá que volver a ellos. Puede hacerlo con el siguiente comando para cada archivo:

chmod +x ./build.sh # where build.sh is the file you want to make executable again