¿Cómo evito los problemas de GIT-svn y svn CRLF como este?

Estoy usando git svn y hoy encontré algunos problemas.

Hice un git svn clone y trabajé en mi proyecto por un time. Después de unos días, he llevado mi trabajo al control remoto svn ( git svn dcommit ). Luego, traté de verificar el proyecto con TortoiseSVN y ver si todo está bien. Desafortunadamente, todo se convirtió en terminaciones de línea Unix y VC6 no pudo abrir el proyecto.

Entonces, mi copy de trabajo de git era CRLF, pero mi copy de trabajo svn era LF. Supongo que git lo convirtió ya sea durante la git commit git svn dcommit o git svn dcommit .

¿Tengo razón en suponer que puedo evitar todo este problema si configuro core.autocrlf = false para mi copy de trabajo de git? ¿Estará la fuerza de dejar nuevas líneas en paz? ¿Hay algo más que deba hacerse para que git svn sea fácil de usar sin causar problemas a mis compañeros de trabajo?

(También puede ser interesante mencionar que he usado git svn en la misma máquina anteriormente, sin tocar la configuration, y esta fue la primera vez que sucedió algo así).

Subversion tiene una posibilidad de configuration de conversión de EOL para los files individuales. Y en realidad, Git también lo tiene en forma de files .gitattributes (attributes 'text' y 'eol'). Para el caso general core.autocrlf no es suficiente.

Si lo configura en falso, todos los files con svn: eol-style = native tendrán una línea LF que termina en la copy de trabajo de git-svn, que no se espera para Windows.

Si lo configura en verdadero, todas las terminaciones de línea se convertirán a LF, y se enviarán a SVN en forma de LF (siempre).

En realidad svn:eol-style=unset debe corresponder al atributo '-text' git (eso significa que no hay conversión), svn:eol-style=LF — a 'eol = lf' attribute y svn:eol-style=CRLF – – al atributo 'eol = crlf'; svn:eol-style=native depende del sistema, por lo que puede controlarse mediante una configuration eol no versionada, por lo que el atributo git correspondiente es '! eol' (eso significaría get la configuration EOL desde core.eol de .git / config).

En lugar de git-svn, puede usar cualquier solución que convierta svn: eol-style a los valores correspondientes de .gitattirbutes para files individuales y viceversa de forma automática. Una solución es la del lado del server: instala SubGit en su repository SVN y solo usa la interfaz Git pura que SubGit creará:

 $ 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 

Luego, en el cliente lo clona y establece core.eol en 'crlf' para Windows y 'lf' para otro sistema operativo (el valor pnetworkingeterminado es 'lf').

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

Y después de eso, Git se comportará de la misma manera que SVN.

Alternativamente, del lado del cliente, puede usar SmartGit : puede clonar el repository SVN con él (no abrir el repository git-svn existente) — y luego convertirá svn: eol-style a .gitattributes. No se requiere configuration core.eol adicional para este caso, SmartGit se preocupará por ello.