El repository de Git blobless

Me pregunto si hay una forma de get commit y objects de tree solo desde un control remoto.

Esto puede sonar como una pregunta tonta, no estoy seguro, soy nuevo en la plomería. Estoy construyendo una aplicación que asocia metadatos con commit de git, autorías y estructura de sistema de files. Mis opciones son build una normalización de los datos en la database con algún tipo de mecanismo de synchronization habilitado para el enlace, o utilizar las poderosas herramientas nativas de git para sincronizar, adjuntar metadatos y consultar el historial.

Sin embargo, dado que en realidad no necesito los objects blob, me ahorraría un dólar o dos en hosting si pudiera deshacerme de ellos de alguna manera. ¿Es esto o cualquier encarnación del concepto posible?

Técnicamente, un object de commit solo nombra un object de tree, y luego el object de tree (una vez encontrado) nombra más treees y blobs. Por lo tanto, un repository de git en el que todos los files de objects blob se "rompan" deliberadamente (p. Ej., Se sobrescriba con un file vacío o incluso se elimine por completo) funcionaría hasta cierto punto, de hecho, en la misma medida en que lo hace si crea tal cosa manualmente:

 $ chmod +w .git/objects/f7/0d6b139823ab30278db23bb547c61e0d4444fb $ : > .git/objects/f7/0d6b139823ab30278db23bb547c61e0d4444fb $ git status # On branch master nothing to commit, working directory clean $ git cat-file -p HEAD:file error: object file .git/objects/f7/0d6b139823ab30278db23bb547c61e0d4444fb is empty fatal: Not a valid object name HEAD:file $ git fsck Checking object directories: 100% (256/256), done. error: object file .git/objects/f7/0d6b139823ab30278db23bb547c61e0d4444fb is empty error: sha1 mismatch f70d6b139823ab30278db23bb547c61e0d4444fb error: f70d6b139823ab30278db23bb547c61e0d4444fb: object corrupt or missing missing blob f70d6b139823ab30278db23bb547c61e0d4444fb 

Claramente es una especie de trabajo. (De hecho, git cat-file -p HEAD y git cat-file -p HEAD: también funcionan aquí, al igual que git ls-tree -r HEAD ).

El problema con el que te vas a encontrar inmediatamente es que git prefiere almacenar objects en packages y transferirlos, y esos notan los objects corruptos (o faltantes, si los tienes). Incluso podría no ahorrar tanto espacio, dependiendo de qué tan comprimidos estén los objects en los packages (se ha observado que el repository es a veces más pequeño que el tree extraído).