¿Cómo puedo gestionar las dependencies de Go mientras verifico el directory de proveedores en el control de versiones?

Context

He escrito una biblioteca de Go y me gustaría conectar y vender las dependencies de terceros. De esta forma, cualquier cambio incompatible con versiones anteriores de estas dependencies de terceros no afectará mi biblioteca para otros usuarios. Consulte la propuesta original para el experimento Vendiendo de Go 1.5 para get información adicional sobre cómo funciona el vendedor.

Estoy usando Glide para administrar dependencies y bloquear versiones específicas. Dado que el proyecto es una biblioteca destinada a que otras personas lo utilicen, me gustaría comprobar la carpeta del proveedor en el control de la versión. De esta forma, los usuarios de la biblioteca no tienen instalado Glide para usarlo. Todo lo que tienen que hacer es establecer la variable de entorno GO15VENDOREXPERIMENT=1 .

He usado Glide en el pasado y estoy muy cómodo con eso. Sin embargo, nunca intenté enviar la carpeta del proveedor al control de versiones antes. Es por eso que de repente me encuentro con problemas. No creo que este sea un problema que Glide deba solucionar, de lo contrario, abriría un problema allí. Realmente, esto me parece un problema con git.

Problema

Estoy usando la versión 2.5.4 de git. Cuando ejecuto la glide install , todas las dependencies se clonan y almacenan en la carpeta del proveedor. Cuando trato de agregar la carpeta del proveedor a git, confusamente intenta crear submodules para ellos. (Creo que tiene que ver con el hecho de que cada dependencia es un repository clonado y todavía tiene un file .git). Este no es el comportamiento que quiero, y me sorprendió que git lo haga de manera pnetworkingeterminada. De hecho, me tomó un time averiguar qué estaba sucediendo realmente y por qué las dependencies no se estaban agregando correctamente.

Los submodules de Git son confusos y rompen muchas herramientas. Solo quiero agregar los proyectos incluidos al control de versiones tal como están. Quiero que todo el código fuente esté allí, como está, para que no estropee ninguna otra herramienta y funcione de la manera que yo quiera.

Pregunta

¿Hay alguna forma de desactivar este comportamiento pnetworkingeterminado en git? Idealmente, podría ser por proyecto. Las únicas opciones relevantes para .gitconfig que pude encontrar parecen estar relacionadas con la visualización de submodules en git diff o git fetch submodules recursivamente con git fetch , pull o clone .

Si no lo hay, ¿hay alguna forma de hacer una sola vez para agregar los files y las carpetas en la carpeta del proveedor sin usar los submodules? Espero algo como git add --no-submodules vendor pero no pude encontrar nada como esto.

Me doy count de que simplemente podría eliminar el file .git en cada dependencia, pero esa solución no es ideal por una serie de razones. Principalmente, yo u otro contribuyente podría olvidar fácilmente eliminar el file .git y, como resultado, la dependencia no se verificaría correctamente. Tendríamos que recordar hacer esto siempre que actualicemos o agreguemos una nueva dependencia.

Tenga en count que el título original de esta pregunta era "¿Cómo puedo evitar que git use submodules de manera pnetworkingeterminada?". He actualizado el título porque la solución que surgió no implica hacer eso. Por lo que yo sé, no hay forma de evitar que Git use submodules cuando las dependencies que agrega contienen un directory .git.

En cambio, he decidido simplemente dejar que git agregue las dependencies como submodules. Los submodules son ciertamente confusos e incluso vienen con su propio set de commands. Lo que descubrí es que no importa. Los usuarios de la biblioteca nunca tendrán que interactuar directamente con los submodules porque go get y el experimento de proveedor Go funcionará bien. Además, los commands de glide install y glide install también funcionarán.

Por lo tanto, en conclusión, he decidido seguir con los submodules, pero nunca uso los commands del submodule directamente.

También podría estar interesado en ver las notas de la versión 0.14.1 de Zoom , donde implementé este cambio y proporcioné un context adicional. La cuestión Glide # 112 también proporciona más información sobre el problema.

Actualización: hablé demasiado pronto. Parece que el uso de submodules de la forma en que lo hice (que es solo el uso del comportamiento pnetworkingeterminado de git) causa problemas con go get cuando se instala desde cero. Estoy deseleccionando esta como la respuesta elegida hasta que pueda encontrar la manera de hacerlo funcionar.