Come cambia Git Track, perché viene confuso? Perché faccio

Ho un repository git su una cartella Dropbox, condivisa tra una macchina Linux e una macchina Windows. Cerco di sincronizzare solo sul computer Windows, perché sono a conoscenza di "problemi" che possono sorgere. Di tanto in tanto faccio un piccolo commit sulla scatola di Linux, per tenere traccia delle mie modifiche,

Ma ora sono davvero curioso, cosa sta facendo git: Id non ha toccato il file fonttest.tex, ma git mi ha riferito che è stato modificato:

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

E l' diffelenco elenca l'intero file: tutte le righe vengono eliminate e inserite di nuovo. Ok, probabilmente un problema CRLF. Quindi chiedo todose fromdosconvertire avanti e indietro con e senza CR e CRLF. Ma - indovina già - nessuna modifica per git: tutte le linee sono cambiate.

Hmm, ho pensato, Dal momento che so che nulla è cambiato, ottengo una copia pulita :

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

E poiché sono una persona curiosa, voglio vedere la differenza:

diff fonttest.tex fonttest.tex1

Niente. Veramente?

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

Veramente. E cosa ci sta pensando Git ?

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

Amico, l'hai appena verificato per me! Qual è il problema qui? Perché git pensa che il file sia cambiato?

Ecco un estratto della mia configurazione. Ho fatto alcuni aggiustamenti riguardanti CRLF, seguendo il consiglio di qualcuno per la condivisione di Dropbox. Ma ... non riesco a seguire Git qui.

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

Anche se probabilmente va bene conservare un repository Git all'interno di una cartella Dropbox, il problema è che più sistemi condivideranno una directory di lavoro e un indice se li mantieni lì. Git non è stato progettato per questo tipo di utilizzo.

La mia ipotesi è che il problema che stai riscontrando abbia qualcosa a che fare con questo. Forse è un problema di fine linea, poiché la tua macchina Windows utilizzerà \r\nma la tua macchina Linux utilizzerà \n.

Se si desidera utilizzare Dropbox per mantenere sincronizzati i repository Git, consiglierei di mantenere un repository nudo in Dropbox, quindi estrarre e spingerlo da repository separati. In questo modo, il repository nudo verrà sincronizzato tramite Dropbox, ma ciascun sistema operativo manterrà separati i propri indici e directory di lavoro.

Lo faresti sulla tua macchina Linux:

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

Quindi, sul tuo computer Windows, procedi come segue:

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

Da questo punto in poi, faresti tutto il tuo lavoro all'interno ~/latex(Linux) e %USERPROFILE%\latex(Windows). Quando effettui i commit che desideri condividere, li utilizzeresti git push dropbox masterin un repository e git pull dropbox masternell'altro.

Stai estraendo alcune informazioni potenzialmente importanti dall'output dello stato git. Lo stato git dice "Modifiche non messe in scena per il commit" o "Modifiche da commettere". Se dice quest'ultimo, il motivo per cui il file viene sempre visualizzato come modificato è perché hai apportato modifiche senza compromessi all'indice.