¿Cómo maneja git-svn las terminaciones de línea?

Question

Estoy muy contento con la manera en que Git maneja los finales de línea, a través de core.autocrlf, core.eol + gitattributes (Tim's post is excellent).

Tengo un repositorio de Windows Git que tiene autocrlf establecido en true. Por lo tanto, todos los archivos de texto se almacenan en el repositorio como LF y viven en el directorio de trabajo como CRLF. Este repositorio fue clonado de un repositorio SVN, que todavía usamos para enviar desde/hasta (el repositorio SVN es nuestro repositorio central y bendecido para activar CI, etc.).

Pero no sé cómo git-svn maneja los finales de línea durante las operaciones push/pull.

¿Alguien puede explicar lo que hace git-svn en este caso?

Answer 1

Me interesa lo que también sucede. Suponiendo que usted tiene un acuerdo de recompra que se ha creado a través de git clone SVN, creo que se podría dividirlo en tres cuestiones diferentes:

1. ¿Esto sucede cualquier git nueva línea de normalización/alteración en svn git fetch tiempo, en el movimiento compromete desde SVN al git repo?
2. ¿Alguna nueva alteración o normalización de git ocurre en el tiempo de confirmación de git [es decir durante un git local normal comprometerse con un repositorio con controles remotos svn]? ¿Qué hay de combinar/tiempo de rebase?
3. ¿Alguna nueva modificación/normalización de git se produce en git svn dcommit time, en push/repeying/lo que git commits contra svn?

Me gustaría saber lo que se supone teóricamente para ser verdad para estas preguntas, pero por ahora hice un pequeño experimento que parece mostrar que no hay normalización de nueva línea en el caso # 1, al menos:

rem We'll make a svn repo with CRLF newlines, clone it into git with 
rem autocrlf enabled, and try to see if that results in LF-only newlines 
rem getting stored in the git repo 

cd c:\code 

rem Step 1. Prepare SVN repo with CRLF type newlines. 
rem The pre-1.4 flag is to prevent an error during git clone. 

svnadmin create --pre-1.4-compatible svnrepo 
svn checkout file:///C:/code/svnrepo svnworking 
cd svnworking 
echo "First line" > file.txt 
echo "Second line" >> file.txt 
echo "Third line" >> file.txt 
rem NOTE: At this point file.txt has CRLF newlines 
svn add file.txt 
svn commit -m "Add file.txt" 
rem NOTE: At this point file.txt still has CRLF newlines 
cd .. 

rem Step 2. Clone the svn repo into git and inspect work copy newline type 
git svn clone file:///C:/code/svnrepo gitrepo 
rem The following outputs true on my machine 
git config --get core.autocrlf 
cd gitrepo 
rem The following also outputs true on my machine 
git config --get core.autocrlf 
git svn fetch 
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines 

rem Step 3. Disable autocrlf to inspect repo's inner newline type 
rem Use the following and my editor to set core.autocrlf to false: 
git config --edit --local 
rem This now prints false: 
git config --get core.autocrlf 
git checkout . 
rem NOTE: At this point file.txt (git working dir copy) still has CRLF newlines 
del file.txt 
git checkout . 
rem NOTE: Even after explicitly deleting the old one and checking out again, 
rem file.txt still has CRLF newlines 

Si la conversión de git newline hubiera tenido lugar durante mi extracción de git svn, en cambio, esperaría que file.txt tuviera líneas nuevas solo de LF al final de todo esto.

Aquí hay una comprobación de validez que el paso 3 anterior aplica efectivamente una prueba válida de que el repositorio tiene LF-sólo los saltos de línea:

rem We'll a git repo with core.autocrlf on, then switch it off to 
rem pull out a file 

rem The following outputs true 
git config --get core.autocrlf 
git init gitcrtest 
cd gitcrtest 
rem The following still outputs true 
git config --get core.autocrlf 
echo "First line" > file.txt 
echo "Second line" >> file.txt 
echo "Third line" >> file.txt 
git add file.txt 
git commit -m "Add file.txt" 
rem NOTE: At this point file.txt (git working dir copy) has CRLF newlines 
rem Use the following to set core.autocrlf to false 
git config --edit --local 
git checkout . 
rem NOTE: Now file.txt (git working dir copy) has LF-only newlines 

En resumen: Con base en lo anterior, parece que cuando git-svn tira desde svn, las confirmaciones de svn se agregan al gráfico de confirmación de git sin ninguna traducción crlf, incluso cuando está habilitado el autocrlf. Es decir, cualquier tipo de línea nueva que tengan sus archivos en su repositorio de svn, también lo tendrán en su clon de git. (Pero su copia de trabajo del git puede tener diferentes tipos de línea nueva.)

Tenga en cuenta que esto es bastante coherente con la discusión de la normalización de fin de línea en "atributos de ayuda de git"; la normalización se presenta como algo que sucede con comandos que extraen material del repositorio en su directorio de trabajo (por ejemplo, pago o fusión) o con comandos que mueven cosas de su directorio de trabajo al índice/repositorio (por ejemplo, agregar o confirmar). "Git svn fetch" no parece hacer ninguna de esas cosas, por lo que tiene sentido que no ocurra una normalización al final de la línea en ese momento. Estoy más confuso sobre lo que hace DCommit, por lo que no estoy seguro de si esperar la normalización de fin de línea en ese momento.

Nota hay una arruga adicional si la propiedad svn: eol-style de SVN está configurada en su repositorio/máquina.I piensa que el valor predeterminado de SVN es no hace conversiones al final de la línea en su extremo, pero no estoy 100% seguro.

Actualización: Para una perspectiva de migración de svn-> git del mundo real en las nuevas líneas, consulte también Tim Abell's description de las mismas. Las líneas nuevas CRLF no se convirtieron en líneas nuevas solo LF por git-svn, con resultados no ideales si la normalización automática de fin de línea de git se dejaba activada. Las soluciones debían normalizar los finales de línea en git o desactivar la normalización de fin de línea.