git - tortoise - sourcetree

¿Cómo elimino los archivos que dicen "old mode 100755 new mode 100644" de los cambios sin organizar en Git?

Question

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

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

old mode 100755
new mode 100644

Alguien sabe que significa esto?

¿Cómo puedo sacar estos archivos de mi lista de cambios no programados? (Es muy molesto tener que pasar por cientos de archivos, solo para seleccionar los archivos que he editado recientemente y que quiero confirmar).

Answer 1

Acabo de encontrarme con este problema al diferenciar mi sucursal con el maestro. Git devolvió un error de ''modo'' cuando esperaba que mi rama fuera idéntica a la maestra. Arreglo al eliminar el archivo y luego volver a fusionar el master.

Primero corrí el diff:

git checkout my-branch
git diff master

Esto volvió:

diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644

Luego corrí lo siguiente para arreglarlo:

rm bin/script.sh
git merge -X theirs master

Después de esto, git diff no devolvió diferencias entre my-branch y master.

Answer 2

Establecer core.filemode en falso no funciona. Pero se aseguraría de que las configuraciones en ~ / .gitconfig no sean anuladas por aquellas en .git / config.

Answer 3

Esto sucede cuando se extraen y todos los archivos se pueden ejecutar en el repositorio remoto. Hacerlos ejecutables de nuevo hará que todo vuelva a la normalidad nuevamente.

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 establecieron como ejecutables y que se modificaron debido a la operación anterior. Hay una mejor manera de hacer esto, pero esto es solo una solución muy rápida y sucia.

Answer 4

He encontrado este problema al copiar un repositorio git con archivos de trabajo de un disco duro antiguo un par de veces. El problema se deriva del hecho de que el propietario y los permisos cambiaron de la unidad / máquina anterior a la nueva. El largo y corto de esto es, ejecute los siguientes comandos para arreglar las cosas ( gracias a esta respuesta del superusuario ):

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

El comando anterior realmente resolverá las diferencias que git diff informó, pero revocará su capacidad de enumerar los directorios, 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 archivos que desea mantener, como los scripts .sh , deberá revertirlos. Puedes hacerlo con el siguiente comando para cada archivo:

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

Answer 5

Me rwxr-xr-x modos de permisos de archivos Unix ( 755 = rwxr-xr-x , 644 = rw-r--r-- ): el modo antiguo incluía el indicador + x (ejecutable), el nuevo modo no.

Las respuestas de este problema de msysgit sugieren establecer core.filemode en falso para deshacerse del problema:

git config core.filemode false

Answer 6

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 7

Puede probar git reset --hard HEAD para restablecer el repositorio al estado predeterminado esperado.

Answer 8

Solo tenía un archivo problemático con los permisos modificados. Para revertirlo individualmente, simplemente lo borré manualmente con rm <file> y luego realicé una extracción para obtener una copia nueva.

Por suerte no lo había puesto en escena todavía.

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