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

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

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

 old mode 100755 new mode 100644 

Alguien sabe que significa esto?

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

A mí me rwxr-xr-x modos de permissions de files unix ( 755 = rwxr-xr-x , 644 = rw-r--r-- ) – el antiguo modo incluía el indicador + x (ejecutable), el nuevo modo no.

Las respuestas de este número de msysgit sugieren establecer core.filemode en false para eliminar el problema:

 git config core.filemode false 

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

Podría intentar restablecer git –hard HEAD para restablecer el repository al estado pnetworkingeterminado esperado.

Parece que ha cambiado algunos permissions del directory. Hice los siguientes pasos para restaurarlo.

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

Me he encontrado con este problema al copyr un repository git con files de trabajo de un disco duro viejo un par de veces. El problema surge del hecho de que el propietario y los permissions cambiaron de la unidad / máquina anterior a la nueva. En resumen, ejecute los siguientes commands para aclarar las cosas ( gracias a esta respuesta del superusuario ):

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

El antiguo command resolverá las diferencias que git diff informó, pero revocará su capacidad para listr los directorys, por lo que ls ./ falla con ls: .: Permission denied . Para arreglar eso:

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

La mala noticia es que si tiene algún file que quiera mantener ejecutable, como los scripts .sh , deberá revertirlos. Puede hacerlo con el siguiente command para cada file:

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

Solo tenía el file problemático con los permissions modificados. Para retrotraerlo individualmente, lo eliminé manualmente con rm <file> y luego hice un checkout para get una nueva copy.

Afortunadamente aún no lo había organizado.

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

Esto sucede cuando tira y todos los files fueron ejecutables en el repository remoto. Hacerlos ejecutables de nuevo volverá a poner todo en order.

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

Es posible que deba hacer:

 chmod -x <file> // Removes execute bit 

en cambio, para files que no se establecieron como ejecutables y que se cambiaron debido a la operación anterior. Hay una mejor manera de hacerlo, pero esto es solo una solución muy rápida y sucia.