git-svn - migrar svn a git

¿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 ( la publicación de Tim es excelente ).

Tengo un repo de Windows Git que tiene el autocrlf establecido en true . Entonces, 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

Estoy interesado en esto también. Supongamos que tiene un repositorio creado a través de git svn clone, creo que podría dividirlo en tres preguntas diferentes:

1. ¿Alguna nueva modificación / normalización de git ocurre en git svn fetch time, en mover commits de svn al git repo?
2. ¿Algún git newline normalización / alteración ocurre en git commit time [es decir, durante un commit de git local normal a un repositorio con controles remotos svn]? ¿Qué hay de combinar / tiempo de rebase?
3. ¿Alguna nueva modificación / normalización de git ocurre en git svn dcommit time, en push / repeying / lo que sea que git se comprometa contra svn?

Me encantaría escuchar lo que teóricamente se supone que es cierto para estas preguntas, pero por ahora hice un pequeño experimento que parece mostrar que no hay una nueva línea de normalización 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 git svn pull, en cambio, esperaría que file.txt tuviera líneas nuevas solo de LF al final de todo esto.

Aquí hay una verificación de cordura de que el paso 3 anterior realmente implementa una prueba válida de si el repositorio tiene líneas nuevas solo de LF:

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: en función de lo anterior, parece que cuando git-svn extrae de 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 de git puede tener diferentes tipos de nueva línea).

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.

Tenga en cuenta que hay una arruga adicional si se establece la propiedad svn: eol-style de SVN en su repositorio / máquina. Creo que el valor predeterminado de SVN es no hacer conversiones al final de la línea, pero no estoy 100% seguro.

Actualización : Para una perspectiva de migración real de svn-> git en las nuevas líneas, ver también la descripción de Tim Abell de la misma. 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.