sergio/takana
> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…
takana etapa 5c: comentarios de scripts, MOTD, y un BUG que introdujo la etapa 4
1#!/bin/sh
2# mirror-git-poblar.sh — espeja las fuentes GIT del corpus como bundles (ADR 0013).
3#
4# ── POR QUÉ BUNDLES SHALLOW Y NO CLONES COMPLETOS ──────────────────────────────────────────────
5# Takana no usa la historia: lo único que hace con un repo es `git archive <commit> | tar -x`, o sea
6# materializar UN árbol. Un clon `--depth 1` del commit exacto basta, y para `act` son 8,9 MB en
7# lugar del repositorio entero. Con 606 fuentes git, la diferencia decide si el mirror cabe.
8#
9# El objeto se nombra por CONTENIDO igual que los tarballs: `takana/fuentes-git/{commit}.bundle`.
10# El commit ES su verificación — git comprueba cada objeto contra su SHA al desempaquetar, así que
11# un bundle alterado no pasa. No hace falta índice ni sha256 aparte.
12#
13# ── EL FICHERO `shallow` NO SE SUBE ────────────────────────────────────────────────────────────
14# Un bundle hecho desde un repo shallow no lleva la frontera de historia, y al desempaquetarlo git
15# aborta con «Failed to traverse parents». Suena a bundle incompleto y NO lo es: los objetos llegan
16# enteros. La frontera de un clon `--depth 1` es exactamente el commit pedido, así que el lado que
17# consume la reconstruye sola (lo hace `hidratar_desde_bundle` en fetch.rs). Nada que transportar.
18#
19# Uso: scripts/fuentes/mirror-git-poblar.sh # todas las que falten
20# LIMITE=20 scripts/fuentes/mirror-git-poblar.sh # sólo las 20 primeras
21# SOLO=mesa scripts/fuentes/mirror-git-poblar.sh # una receta concreta
22set -eu
23ROOT="$(cd "$(dirname "$0")/../.." && pwd)"; cd "$ROOT"
24exec python3 scripts/fuentes/mirror-git-poblar.py "$@"