Tus reuniones, en commits dentro de tu propio repositorio

El registro de Earkeep ya son archivos sin formato: un archivo JSONL por día, en la carpeta que elijas, a menudo dentro del repositorio donde viven tus notas. Pero una carpeta solo tiene versiones si alguien hace commit, y hacerlo a mano deja de ocurrir hacia el miércoles. Por eso Earkeep hace los commits y deja el resto del repositorio en tus manos.

Solo se activa dentro de un repositorio. Cuando la carpeta de transcripciones, o una carpeta superior, es un repositorio Git, Ajustes → Almacenamiento y Git ofrece la función. Si no, hay un único botón que ejecuta git init, la única forma en que Earkeep crea un repositorio.

Tú eliges cuándo hace commit: cuando termina un día, cuando cambia una reunión, en ambos casos (el valor predeterminado) o nunca.

• Cuando termina un día significa cinco minutos después de la medianoche. Si el portátil está en suspensión a medianoche, hace el commit de ayer al despertar.
• Cuando cambia una reunión significa guardada, terminada, redimensionada, renombrada o eliminada, unos segundos después de la última edición, de modo que arrastrar un borde es un solo commit. Que empiece una reunión no genera ningún commit, ni tampoco las líneas nuevas de transcripción por sí solas.

Un commit por archivo diario y nada más. Lo que hayas añadido tú al área de preparación se queda fuera de los commits de Earkeep, y un archivo diario que tu .gitignore excluya se deja fuera.

Solo en una rama que permitas: main (o master), la rama que esté activa o una que nombres tú. En cualquier otra rama no se hace ningún commit y Ajustes explica por qué.

Cada mensaje nombra el día y la reunión, así que git log --oneline se lee como la semana que has tenido:

Cada mensaje es una plantilla que puedes reescribir en Ajustes, una por evento, con {date} y {meeting} como marcadores.

Haz push a todos los remotos (el valor predeterminado), a los remotos que elijas o a ninguno, y cada commit se queda en tu dispositivo.

Esta es la única vía por la que una transcripción sale de tu dispositivo, y solo hacia un remoto que hayas configurado tú, con tu propia cuenta. Earkeep no tiene ningún servidor en ese camino.

Es tu propio Git, así que tu agente SSH, tus gestores de credenciales y tus hooks se aplican igual que en una terminal. Un push que pidiera contraseña o frase de paso falla de inmediato y dice por qué, en lugar de quedarse esperando a un aviso que nadie ve.

Un remoto que ha avanzado se integra, no se rechaza. Earkeep hace lo que hace git pull --rebase --autostash y después hace push. La grabación continúa; la edición de reuniones se pausa en ese momento y te lo indica.

Cuando los commits del remoto entran en conflicto con los tuyos, Earkeep entrega el rebase detenido a uno de los agentes ACP de tu equipo, como Claude Code o Codex. Después comprueba el repositorio, no la respuesta del agente: que el rebase haya terminado, que estén los commits de ambos lados y que no quede ninguna marca de conflicto. Solo entonces hace push.

Todo lo que no llegue a eso se deshace: se aborta el rebase, tu rama y tus cambios sin confirmar vuelven a como estaban, y Earkeep te cuenta lo que dijo el agente. El agente es tu propia herramienta con tu propia clave, así que lo que lee va adonde ese agente suele enviarlo.

Un fallo aparece sobre la transcripción con palabras claras (el remoto rechazó tu clave, no se pudo contactar con el host, un conflicto necesita tu atención), con las palabras del propio Git debajo. Earkeep reintenta cada cinco minutos, así que, una vez arreglada la causa, el push sale.

• Privado por diseño: los archivos de los que se hace commit.
• Agentes y MCP: los agentes que escriben tus actas y resuelven tus conflictos.
• PKM para desarrolladores: las notas como repositorio Git.
• La wiki con LLM: en qué se convierte una carpeta de reuniones con versiones.