Organizando Libs externos en Git para varios proyectos

El problema

Quiero que mi empresa almacene todas las bibliotecas externas incluidas en el control de código fuente, pero me gustaría que estas bibliotecas externas estén en un repository único (no incluido en cada proyecto individual) ya que hay bastantes librerías, y son grandes.

Técnica anterior

Esta pregunta aborda el problema, pero nadie respondió directamente. (¿Cómo organizo mi repository Git [mejor título apreciado])

Esto describe bastante bien una situación similar, pero no dados. (Git, sub-repos y libs externos para desarrollo web: ¿la mejor estrategia de una vez por todas?)

Esto definitivamente responde la pregunta, pero usa submodules. (Mejores prácticas para repositorys Git con múltiples proyectos en el layout tradicional de n niveles)

Git Slave suena genial, pero preferiría no agregar otra herramienta git a nuestro repertorio ya que git es nuevo para nosotros.

Esto es lo que estoy pensando hasta ahora.

my coding dir/ app1/ .git/ src/ com/ ... app2/ .git/ src/ com/ ... ext libs/ .git/ server crap/ apache tomcat 7.0.123/ ... apache cxf versionnumber/ ... util crap/ someones really great util lib-1.0/ ... 

Y luego habría una variable $ PATH en una configuration o similar que apuntaría al directory lib.

Más pensamientos

  • No tenemos un ingeniero de infraestructura, y como no quiero estar de guardia cada vez que alguien necesita agregar o actualizar una lib, me gustaría alejarme del submodule de git porque me parece complicado. Me alegra seguir con eso en el futuro, pero solo estamos comenzando a beber del git koolaid.
  • También estoy contento de utilizar submodules ahora si alguien puede indicarme una explicación clara de lo que es y un tutorial claro sobre cómo usarlo para poder pasar esta información a mis compañeros. No quiero que todos lean dos horas de documentation sobre temas avanzados mientras que ahora nos estamos poniendo de pie con Git.
  • Sería bueno vincular versiones del repository de lib con las versiones de los repos de aplicaciones.

Una vez más, puedo ser convencido de mi sentimiento anti-submodule, pero el hecho de que los tutoriales que puedo encontrar estén desactualizados y / o confusos es una gran decepción. Esto debe ser un process fácil para cualquier ingeniero y fácil de deshacer. ¡No somos git ninjas!

Por último, no sé si importa, pero todos estamos en Unix, y todos java todo el time.

¡Gracias por adelantado!

Actualización 3-1-2012

Estoy a punto de hacer llorar al bebé Linus Torvalds.

He estado haciendo una buena cantidad de investigación, y mi conclusión es que los submodules son geniales si ya eres un ninja git . Entonces, dicho esto, voy a hacer lo incorrecto y crear un directory de libs en cada proyecto de git. ¿Por qué? Es más fácil, y es una gran mejora sobre lo que estamos haciendo actualmente. También asume un umbral mucho más bajo de conocimiento de git. Un día, cuando todos seamos sólidos en los conceptos básicos e intermedios de git (¿parches, historia de reescritura, ramificación avanzada?), Es probable que pasemos a los submodules. Tal como están las cosas, no quiero configurar a mis ingenieros para el fracaso al darles demasiado para masticar.

Esperemos que entre ahora y cuando estemos listos para avanzar hacia la "forma correcta", los submodules serán less nudosos.

Los submodules están diseñados para esto. Por favor apréndalos. ProGit.org/book es un gran recurso. Ver el Capítulo 6, sección 6 (Lo he asignado a la memory).

Estaré encantado de ayudar a través de Twitter / correo electrónico si tiene alguna otra pregunta. La misma identificación que la que uso aquí.