Unsync'd repositorio Git en Dropbox

Question

Tengo un repositorio git (y directorio de trabajo) que se almacena en mi cuadro de selección para que pueda avanzar y retroceder entre ordenadores sin tener que comprometerse o escondite (es decir: sin ningún esfuerzo en absoluto) . Esto funciona muy bien a excepción de una pequeña molestia que se está convirtiendo en una gran molestia.

De vez en cuando, voy a dejar una computadora en un estado completamente comprometido solo para levantar la otra computadora y encontrar que un git status informa cambios. Inevitablemente, esos cambios están relacionados con los permisos. De lo que no estoy seguro es de ¿por qué? Supuse que podría estar relacionado con la forma en que Dropbox escribe archivos en computadoras sincronizadas, pero el umask en ambos sistemas está configurado en 0002. Supongo que ese valor dicta el modo de archivos escritos/actualizados por Dropbox, pero no lo haría ser la primera vez que estaría equivocado

sé que solo puedo decir a Git que ignore el modo de archivo, pero eso es sólo enmascarar el problema. Realmente me gustaría entenderlo para poder tomar una decisión informada sobre cómo proceder.

Gracias.

ACTUALIZACIÓN

Así que aquí es un ejemplo representativo bastante decente de un repositorio se salga de sincronismo pesar de que está totalmente contenido dentro de Dropbox. En estos momentos, mi portátil personal está reportando un directorio de trabajo limpio para uno de mis proyectos:

$ git status 
# On branch develop 
nothing to commit (working directory clean) 

Mi portátil de trabajo, sin embargo, reporta una serie de sin seguimiento archivos. Permítanme decirlo de nuevo: sin seguimiento archivos.

$ git status 
# On branch develop 
# Untracked files: 
# (use "git add <file>..." to include in what will be committed) 
# 
# html/cake/console/libs/templates/ 
# ...4 more files... 
# html/cake/tests/test_app/plugins/test_plugin/views/themed/ 
nothing added to commit but untracked files present (use "git add" to track) 

¿Cómo puede ser eso? Mi archivo ~/.gitignore también se comparte en ambas máquinas (no se excluye ninguna de estas rutas en un archivo de ignorar). ¿Hay algún otro componente de Git, o tal vez Dropbox, que pueda estar en juego aquí?

Answer 1

He conseguido este problema exacto en las mismas circunstancias.

Para detener los archivos mostrando en git status puede configurar Git para ignorar los cambios de modo de archivo:

git config core.filemode false 

Este cambio es local al repositorio Git y se sincronizará junto con los archivos.

Answer 2

Es posible que desee comprobar dónde está configurando su máscara de usuario; puede ser que Dropbox esté comenzando con una umask diferente a la que tiene tu shell. Sin embargo, creo que git ignora el grupo/otros permisos y se preocupa principalmente por el bit de ejecución, que no debería verse afectado por umask. Algunos pensamientos para la depuración:

• ¿Se puede reproducir a pedido? ¿Cómo?
• ¿Con qué sistemas operativos está sincronizando?
• Si git checkout -f en los archivos en cuestión, ¿Reciben los permisos correctos?
• Si simplemente chmod un archivo en un sistema, ¿ese cambio se propaga?

Answer 3

El hecho de que esté utilizando Mac es relevante; el Macworld Hints article mencionado en un comentario explica el problema (pero lea el comentario que explica cómo arreglar permisos con chmod u+rwX etc., en lugar de permisos absolutos que pueden complicar las cosas).

Este Dropbox Support answer explica lo que probablemente está pasando y cómo solucionarlo, relacionado con cómo MacOS X Leopard (10.5) cambió el uso predeterminado de las ACL.