Come evitare problemi di Git-svn e svn CRLF come questo?

Question

Sto usando git svn e oggi ho avuto qualche problema.

Ho fatto un git svn clone e ho lavorato al mio progetto per un po '. Dopo alcuni giorni, ho spinto il mio lavoro su svn remote (git svn dcommit). Poi ho provato a controllare il progetto con TortoiseSVN e vedere se tutto è giusto. Sfortunatamente, tutto è stato convertito in terminazioni di linea Unix e VC6 non è riuscito ad aprire il progetto.

Quindi, la mia copia di lavoro git era CRLF, ma la mia copia di lavoro svn era LF. Sto assumendo git convertito sia durante git commit o git svn dcommit.

Ho ragione di supporre che posso evitare tutto questo problema se ho impostato core.autocrlf = false per la mia copia di lavoro Git? Questa forza andrà a lasciare le newline da solo? C'è qualcos'altro che deve essere fatto per rendere git svn facile da usare senza causare problemi ai miei colleghi?

(Può anche essere interessante menzionare che ho usato git svn sulla stessa macchina prima, senza toccare le impostazioni, e questa era la prima volta qualcosa di simile è accaduto.)

Answer 1

Subversion ha una possibilità di Impostazioni di conversione EOL per i singoli file. E in realtà Git lo ha anche in una forma di file .gitattributes (attributi 'testo' e 'eol'). Per il caso generale, core.autocrlf non è sufficiente.

Se lo si imposta su falso, tutti i file con svn: eol-style = nativo avranno la riga LF che termina con la copia di lavoro git-svn, che non è prevista per Windows.

Se si imposta su true, tutte le terminazioni di riga verranno convertite in LF e saranno inviate a SVN sotto forma di LF (sempre).

realtà svn:eol-style=unset dovrebbe intendere '-text' attributo git (che significa nessuna conversione), svn:eol-style=LF --- a 'eol = lf' attributo e svn:eol-style=CRLF --- a 'eol = crlf' attributo; svn:eol-style=native dipende dal sistema, quindi può essere controllato da un'impostazione eol non verificata, quindi l'attributo git corrispondente è '! Eol' (che significherebbe ottenere l'impostazione EOL da core.eol di .git/config).

Invece di git-svn, è possibile utilizzare qualsiasi soluzione che converta svn: stile eol ai valori corrispondenti .gitattirbutes per i singoli file e viceversa automaticamente. Una soluzione è il lato server: si installa SubGit nel repository SVN e basta usare l'interfaccia Git pura che SubGit creerà:

$ subgit install path/to/svn/repository 
# Git interface with correct .gtattributes repository will appear at path/to/svn/repository/.git 
# you should setup an access to it 

Poi al cliente si clona e impostare core.eol a 'crlf' per Windows e 'lf' per altri SO (il valore predefinito è 'lf').

$ git clone <URL> working_tree 
$ cd working_tree 
$ git config core.eol crlf #for Windows only 

E dopodiché Git si comporterà nello stesso modo di SVN.

alternativa sul lato client non c'è si può usare SmartGit: è possibile clonare il repository SVN con esso (non aperto repository git-svn esistente) --- e poi verrà convertito svn: eol-style a .gitattributes. Per questo caso non è richiesta alcuna impostazione core.eol aggiuntiva, SmartGit si prenderà cura di esso.