ikurotime / gitgud

Los bare viven en el filesystem del contenedor (GITGUD_DATA_DIR=/data, VOLUME ["/data"]), o sea en /data/repos/<owner>/<name>.git del host donde cayó. Los repositorios quedan atados a un nodo, una segunda réplica serviría un /data vacío, y perder el volumen es perder todo.

Va con el issue de PostgreSQL: sacar la DB no sirve mientras los repos sigan adentro.

"Apuntarlo a S3" no funciona

Hay tres consumidores de ReposDir() y dos necesitan un filesystem POSIX real:

git-http-backend vía CGI (http_backend.go)	Todo el clone/push. Programa en C que abre archivos y toma locks. No se le puede apuntar a object storage.
CLIGit (cli_git.go)	git init --bare, y para merges clone/merge/push sobre os.MkdirTemp. Misma restricción.
GoGitReader (gogit_reader.go)	Solo la UI de navegación. Este sí es flexible: go-git lee vía billy, que ya está como dependencia indirecta.

El camino de lectura puede irse a un bucket barato. El de escritura no, salvo reemplazando el binario de git.

Opciones

Opción	Coste	Qué resuelve
A. Filesystem de red (EFS/NFS/CSI)	Casi cero código — sigue siendo POSIX	Durabilidad + multi-nodo. Ojo: git sobre NFS tiene problemas de locking
B. Bucket durable + disco local como caché	Alto: necesita lock distribuido, evicción, y qué hacer si se cae entre push y subida	Durabilidad + multi-nodo + coste
C. Reemplazar http-backend y el CLI por go-git puro sobre billy	El más grande	Elimina POSIX y el binario git (habilita imagen distroless)
D. Volumen persistente + backups	Mínimo	Solo durabilidad, sin multi-nodo

Pregunta abierta

¿Cuál es el objetivo? Las opciones divergen mucho:

• Solo no perder repos al redesplegar -> D o A
• Escalar a varios nodos -> A o B
• Coste / repos grandes -> B
• Soltar el binario git y achicar la imagen -> C, y solo C

Nota

La costura es Config.ReposDir(); nada tiene la ruta hardcodeada. Cualquier backend nuevo debe pasar por repoPath/safeSegment de cli_git.go en vez de construir claves por su cuenta — ya rechazan path traversal y hay tests que lo cubren.