Como o git controla as mudanças, por que isso se confunde? Porque eu faço

Question

Eu tenho um repositório git em uma pasta do Dropbox, compartilhado entre uma máquina Linux e uma máquina Windows. Eu tento sincronizar apenas na máquina Windows, porque estou ciente de "problemas" que podem surgir. Ocasionalmente, eu faço um pequeno commit na caixa do Linux, para rastrear minhas alterações,

Mas agora estou realmente curioso, o que o git está fazendo: eu não toquei no arquivo fonttest.tex , mas o git reportou que ele foi modificado:

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

E o diff lista o arquivo inteiro: Todas as linhas foram excluídas e inseridas novamente. Ok, provavelmente um problema CRLF. Por isso, peço ao todos e ao fromdos que convertam o programa com e sem o CR e o CRLF. Mas - você já adivinhou - nenhuma mudança para git : Todas as linhas foram alteradas.

Hmm, pensei, como eu sei nada mudou, recebo uma cópia limpa :

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

E porque sou uma pessoa curiosa, quero ver a diferença:

diff fonttest.tex fonttest.tex1

nada. Realmente?

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

Realmente. E o que é que se pensa nisso ?

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

Cara, você acabou de verificar para mim! Qual é o problema aqui? Por que o git está pensando que o arquivo foi alterado?

Aqui está um trecho da minha configuração. Fiz alguns ajustes sobre o CRLF, seguindo a dica de alguém para o compartilhamento do Dropbox. Mas ... eu simplesmente não posso seguir o git aqui.

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

    

Answer 1

Embora seja provavelmente bom manter um repositório Git dentro de uma pasta Dropbox, o problema é que vários sistemas estarão compartilhando um diretório de trabalho e um índice se você mantê-los lá. O Git não foi projetado para esse tipo de uso.

Meu palpite é que o problema que você está enfrentando tem algo a ver com isso. Talvez seja uma questão de fim de linha, já que sua máquina Windows usará \r\n , mas sua máquina Linux usará \n .

Se você quiser usar o Dropbox para manter os repositórios do Git em sincronia, eu recomendaria manter um repositório vazio no Dropbox, depois extrair e enviar para ele de repositórios separados. Dessa forma, o repositório vazio será sincronizado via Dropbox, mas cada sistema operacional manterá seus próprios diretórios e índices separados.

Você faria isso na sua 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

Em seguida, na sua máquina Windows, faça isso:

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

Deste ponto em diante, você faria todo o seu trabalho dentro de ~/latex (Linux) e %USERPROFILE%\latex (Windows). Quando você faz commits que deseja compartilhar, você usaria git push dropbox master em um repo e git pull dropbox master no outro.

    

Answer 2

Você está obtendo informações potencialmente importantes da saída de status do git. O status git diz "Alterações não preparadas para confirmação" ou "Alterações a serem confirmadas". Se ele disser o último, a razão pela qual o arquivo está sempre sendo exibido como modificado é porque você efetuou alterações não-modificadas no índice.