empuje git-subárbol --squash necesita mucho tiempo, y se está volviendo más largo en el tiempo con más confirmaciones

Question

He estado usando la extensión del subárbol git (https://github.com/apenwarr/git-subtree). utilizo "--squash" para hacer el registro de proyecto principal limpia, mis pasos como este:

1. añaden lib en el proyecto principal subárbol

   git add sub -P/libdir --squash lib_remote dominar

2. actualización de obtener de lib

   git subárbol -P tirón sub/libdir --squash lib_remote maestro

3. cambios empuje a lib_remote

   git subárbol empuje -P sub/libdir --squash lib_remote maestro

Funciona muy bien para mí (tanto del proyecto principal y lib, tener un historial buen sentido). El problema es el momento del empuje del subtítulo git, se vuelve más largo y más largo.

Mi propósito de utilizar git-sub árbol es casi lo mismo con Screndib, que pidió git-subtree is not retaining history so I cannot push subtree changes, how can I fix this/avoid this issue in the future?

supongo, cuando se utiliza --squash, cada vez que procesar un empujón, sub-árbol git tiene que buscar en toda la historia desde el "subárbol agregar".

¿Cómo puedo reducir el tiempo de inserción del subárbol? ¿O hacer que funcione más eficaz, en lugar de toda la historia, solo cambios de proceso desde el último subproceso git push (o pull)?

Answer 1

Supongo que "lib_remote" en su código indica que la url del repositorio de lib remoto no es una rama en su repositorio actual? Tanto la URL del repositorio remoto como la sucursal de su repositorio actual están funcionando.

Veo que estaba usando git subtree add para agregar el lib remoto como subárbol y luego simplemente usa git subtree push para impulsar los cambios.

Es mejor hacer una operación git subtree split para dividir los cambios del subárbol en una rama separada en su repositorio actual antes de la operación de inserción, luego empujar la rama dividida al repositorio remoto y mantener esta rama dividida, cada vez antes del presionando, haga una operación git subtree split otra vez, esto construirá el historial del subárbol desde el punto en que se dividió por última vez, será mucho más rápido. De lo contrario, sin esta división como lo hiciste, git subreee tiene que compilar la historia de la subree desde el punto que agregaste, siempre y cuando el subárbol se comprometa a crecer, el tiempo del edificio será cada vez más largo.

Si no está usando --squash mientras agrega, puede considerar el uso de --rejoin mientras se divide, esto será mucho más rápido.

Por lo tanto, el paso debe ser el siguiente.

1. añadir lib en el proyecto principal

   git subárbol añada -P sub/libdir --squash lib_remote_url maestro

2. actualización de obtener de lib

   sub-árbol git -P tirón sub/libdir --squash lib_remote_url maestro

3. dividir los cambios del subárbol en una rama separada

   git división subárbol -P sub/LIBDIR -b lib_remote_branch

4. empuje cambios a lib_remote

   git push lib_remote_url lib_remote_branch: master

Mantenga el lib_remote_branch existía y rehacer el paso 3 y paso 4 cuando la próxima vez presione.

Answer 2

El problema principal es con los nuevos commits en diferentes prefijos desde que hiciste tu primer add. Mi solución a este problema es hacer una operación de "limpieza" en la que se filtran todos los cambios que no están en otros repositorios y luego se agrega un subtítulo git en esta nueva rama.

Esta es una forma bastante bruta de hacerlo, pero es básicamente lo mismo que decir hacer un "agregar subtítulo git" en una copia nueva de su repositorio principal. Eso es lo único que funcionó para mí ...