¿Cómo git rastrea los cambios, por qué se confunde? Porque lo hago

Tengo un repositorio git en una carpeta de Dropbox, compartido entre una máquina Linux y una máquina Windows. Intento sincronizar solo en la máquina Windows, porque soy consciente de los "problemas" que pueden surgir. Sin embargo, ocasionalmente hago una pequeña confirmación en el cuadro de Linux para rastrear mis cambios,

Pero ahora tengo mucha curiosidad, qué está haciendo git: Id no tocó el archivo fonttest.tex, pero git me informa que se ha modificado:

towi@havaloc:~/Dropbox/latex$ git status fonttest.tex
# On branch master
...
#   modified:   fonttest.tex

Y las difflistas de todo el archivo: todas las líneas borradas, y se insertan de nuevo. Ok, probablemente un problema de CRLF. Por lo tanto, pido todosy fromdosconvertir de ida y vuelta con y sin CR y CRLF. Pero, supongo que ya no hay cambios para git: Todas las líneas cambiaron.

Hmm, pensé, ya que sé que nada ha cambiado, recibo una copia limpia :

mv fonttest.tex fonttest.tex1
git checkout fonttest.tex

Y como soy una persona curiosa, quiero ver la diferencia:

diff fonttest.tex fonttest.tex1

nada. De Verdad?

towi@havaloc:~/Dropbox/latex$ md5sum fonttest.tex*
d3544bd060504ebb682b2e446375b3b3  fonttest.tex
d3544bd060504ebb682b2e446375b3b3  fonttest.tex1

De Verdad. ¿Y qué está pensando git al respecto ?

towi@havaloc:~/Dropbox/latex$ git status fonttest.tex
# On branch master
...
#   modified:   fonttest.tex

Hombre, ¡acabas de comprobarlo por mí! ¿Qué pasa aquí? ¿Por qué git piensa que el archivo ha cambiado?

Aquí hay un extracto de mi configuración. Realicé algunos ajustes con respecto a CRLF, siguiendo el consejo de alguien para compartir Dropbox. Pero ... no puedo seguir a Git aquí.

towi@havaloc:~/Dropbox/latex$ git config -l       
diff.renames=copies
apply.ignorewhitespace=change
apply.whitespace=nowarn
core.whitespace=cr-at-eol
core.repositoryformatversion=0
core.filemode=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.eol=lf
core.autocrlf=input

Si bien es probable que esté bien mantener un repositorio Git dentro de una carpeta de Dropbox, el problema es que múltiples sistemas compartirán un directorio de trabajo y un índice si los mantiene allí. Git no fue realmente diseñado para este tipo de uso.

Supongo que el problema con el que te encuentras tiene algo que ver con esto. Tal vez sea un problema de final de línea, ya que su máquina Windows lo usará \r\npero su máquina Linux lo usará \n.

Si desea usar Dropbox para mantener los repositorios de Git sincronizados, le recomendaría mantener un repositorio desnudo en Dropbox, luego tire de él y empuje desde repositorios separados. De esta manera, el repositorio simple se sincronizará a través de Dropbox, pero cada sistema operativo mantendrá sus propios directorios e índices de trabajo separados.

Harías esto en tu máquina Linux:

mv ~/Dropbox/latex ~/
cd ~/latex
git init --bare ~/Dropbox/latex.git
git remote add dropbox ~/Dropbox/latex.git
git push dropbox master

Luego, en su máquina Windows haga esto:

cd %USERPROFILE%
git clone Dropbox\latex.git
cd latex
git remote rename origin dropbox

A partir de este momento, haría todo su trabajo dentro de ~/latex(Linux) y %USERPROFILE%\latex(Windows). Cuando realiza confirmaciones que desea compartir, las usaría git push dropbox masteren un repositorio y git pull dropbox masteren el otro.

Estás recortando información potencialmente importante de la salida de estado de git. ¿El estado de git dice "Cambios no organizados para la confirmación" o "Cambios a confirmar". Si dice esto último, la razón por la que el archivo siempre se muestra como modificado es porque tiene cambios no confirmados en el índice.