Submodule de Git sin peso extra

Todavía no soy un maestro de Git, me enfrenté a un problema que no puedo resolver. Tengo un repository con mi esqueleto personalizado de WordPress y he agregado WordPress como un submodule de su repository original por el git submodule add wp_repo_url . Cuando clono mi repository a la máquina local con:

 git clone --recursive https://github.com/user/repo local_dir 

descarga el submodule WP como se esperaba, pero este es el problema: los files reales son solo de 20.7Mb, y en .git/modules/core/objects/pack tengo un gran file .pack de 124Mb, que, supongo, es algo como el historial de commit / revisiones de ese submodule.

¿Cómo puedo volver a agregar el submodule o modificarlo mientras hago la clonación para evitar download este peso extra?

ACTUALIZAR:

Con la ayuda de @iclmam, se me ocurrió la siguiente configuration:

  • mi repository esqueleto tendrá WordPress como submodule, el repository original completo con historial
  • al crear un nuevo proyecto desde esqueleto, lo clonaré sin –opción recursiva para get solo los files principales y la carpeta vacía para el submodule
  • SI necesito WordPress con historial completo, por ejemplo, si necesito cambiar entre diferentes twigs / tags WP para probar mi complemento / compatibilidad retroactiva con el tema, entonces obtendré este submodule con historial completo
  • si solo necesito una installation sencilla y limpia de la versión de WP reciente, me cambiaré al directory de wp y seguiré el path anterior:

     curl -L -O http://wordpress.org/latest.zip unzip latest.zip mv wordpress/* . rm latest.zip rm -rf wordpress 

No es una solución perfecta (quería automatizar todo lo posible), pero funciona por ahora.

Cualquier consejo sobre la pregunta original es apreciado.

desde Git 2.10+ (Q3 2016), podrás hacer un clon regular … y aún beneficiarte de la clonación superficial de los submodules .

Todo lo que necesita hacer es registrar esa configuration en sus .gitmodules :

 git config -f .gitmodules submodule.<name>.shallow true 

Agregar, confirmar y enviar: cualquier persona que clone su repository (clon normal, historial completo) obtendrá solo una profundidad de 1 para el submodule <name> .

Consulte commit f6fb30a , commit abed000 y commit 37f52e9 (03 Ago 2016) por Stefan Beller ( stefanbeller ) .
(Fusionada por Junio ​​C Hamano – gitster – in commit dc7e09a , 08 de agosto de 2016)

> submodule update : learn --[no-]recommend-shallow option

En ocasiones, los proyectos no consideran importante la historia de un submodule. Para que sea más fácil para los usuarios intermedios, permita un campo boolean ' submodule.<name>.shallow ' en .gitmodules , que se puede usar para recomendar si el .gitmodules ascendente considera que el historial es importante.

Este campo se respeta en el clon inicial de manera pnetworkingeterminada, se puede ignorar dando la --no-recommend-shallow .

Si está utilizando WP como un submodule, eso significa que probablemente tenga la necesidad de acceder al historial dentro de ese submodule. Eso significa que necesitas este file de package.

Git empaqueta datos en files de package. Esto es para fines de eficiencia y ahorro de espacio en disco. Ver Git interno – Packfiles . Si se pregunta qué hay en el file de package, puede usar el command git verify-pack . Utilizado con la opción -v, puede descubrir que se ha colocado un file enorme en su repository.

Si por alguna razón quiere "limpiar" el submodule, le sugiero que lea ¿Por qué mi repository es tan grande?

Si no quiere el historial completo en el submodule, puede intentar clonarlo con la opción -depth (ver el command git submodule ), de modo que sea un clon superficial con un historial truncado. Esto podría disminuir el tamaño de la carpeta del package.

1) clonar el repository principal sin la opción recurrente

2) dentro del repository principal, inicialice el submodule usando el command del submodule git con la opción -depth