2.2 KiB
Modificari fantoma git dupa svn update (CRLF)
Simptom: git status arata fisiere ca modified (de obicei .md in COMUN/docs/,
uneori roagest.pjx/.PJT) dupa un ciclu svn update/svn commit, desi git diff
nu arata nicio linie schimbata.
Cauza: SVN scrie fisierele cu CRLF nativ pe Windows si le atinge mtime-ul la fiecare
update, chiar daca continutul nu s-a schimbat. Cu core.autocrlf=true (setare globala
uzuala), git recompara/converteste EOL-urile la fiecare verificare de stat, si uneori
ramane cu index-ul in stare "needs update" desi hash-ul blob-ului e identic cu HEAD
(verificabil cu git hash-object <fisier> vs git ls-files -s <fisier>).
Fix aplicat (2026-07-15): .gitattributes cu * -text la radacina fiecarui repo
(ROAGEST/.gitattributes, COMUN/.gitattributes, si replicat in ROAAUTO, ROACONT)
— dezactiveaza complet normalizarea CRLF/LF facuta de git, SVN ramane singura autoritate
pentru line endings. Fix independent de core.autocrlf local al fiecarui calculator/user.
Daca reapare pe un repo nou (alta aplicatie ROA cu acelasi tipar svn+git in paralel),
copiaza acelasi .gitattributes (* -text) la radacina.
Capcana descoperita ulterior (2026-07-15): * -text opreste doar conversia
automata a git — nu repara divergenta deja existenta intre blob-ul din git (LF,
din commit-ul initial) si ce scrie de fapt SVN pe disc (CRLF nativ Windows). Dupa ce
-text a devenit activ, git status a inceput sa arate din nou aceleasi fisiere
COMUN/docs/*.md ca modificate — de data asta real (CRLF vs LF), nu doar stat-cache.
Fix: normalizat continutul din git la CRLF (ce scrie de fapt SVN), o singura data,
cu un commit pe comun.git (fc11f3e) — de acum ambele parti scriu CRLF, -text
le pastreaza stabile. Daca git status arata iar aceste fisiere modificate dupa un
svn update, verifica intai daca e doar CRLF/LF (diff <(git show HEAD:<f> | tr -d '\r') <(tr -d '\r' < <f>))
inainte sa presupui coruptie de continut.
Diagnostic rapid daca git status minte ca un fisier e curat/murdar:
git hash-object <fisier>
git ls-files -s <fisier> # compara al doilea camp (blob sha) cu output-ul de mai sus
git update-index --refresh # sau git add <fisier> daca hash-urile sunt identice