As suas reuniões, com commit no seu próprio repositório

O registo do Earkeep já são ficheiros simples: um ficheiro JSONL por dia, numa pasta à sua escolha, muitas vezes dentro do repositório onde guarda as suas notas. Mas uma pasta só tem versões se alguém fizer commit, e fazer commit à mão deixa de acontecer logo à quarta-feira. Por isso, o Earkeep faz os commits e deixa o resto do repositório consigo.

Só se ativa dentro de um repositório. Quando a pasta das transcrições, ou uma pasta acima dela, é um repositório Git, Definições → Armazenamento e Git oferece a funcionalidade. Caso contrário, há um botão que executa git init, a única forma como o Earkeep alguma vez cria um repositório.

Você escolhe quando se faz commit: quando um dia termina, quando uma reunião muda, ambos (por defeito) ou nunca.

• Quando um dia termina quer dizer cinco minutos depois da meia-noite. Um portátil em suspensão à meia-noite faz o commit de ontem quando acordar.
• Quando uma reunião muda quer dizer guardada, terminada, redimensionada, renomeada ou eliminada, alguns segundos depois da última edição, por isso arrastar um limite dá um único commit. O início de uma reunião não gera commit, nem as novas linhas de transcrição por si só.

Um commit por ficheiro de dia, e mais nada. O que você próprio colocou em stage fica fora dos commits do Earkeep, e um ficheiro de dia que o seu .gitignore exclua fica de fora.

Apenas num ramo que permitir: main (ou master), o ramo que estiver ativo, ou um que indique. Em qualquer outro ramo não se faz commit e as Definições explicam porquê.

Cada mensagem indica o dia e a reunião, por isso o git log --oneline lê-se como a semana que teve:

Cada mensagem é um modelo que pode reescrever nas Definições, um por evento, com {date} e {meeting} como marcadores.

Faça push para todos os remotos (por defeito), para os que escolher, ou para nenhum, e todos os commits ficam no seu dispositivo.

Esta é a única forma de uma transcrição sair do seu dispositivo, e apenas para um remoto que configurou, na sua própria conta. O Earkeep não tem nenhum servidor nesse caminho.

É o seu próprio Git, por isso o seu agente SSH, os credential helpers e os hooks aplicam-se como num terminal. Um push que pedisse uma palavra-passe ou uma frase-passe falha logo e diz porquê, em vez de ficar à espera de um pedido que ninguém vê.

Um remoto que já avançou é integrado, não recusado. O Earkeep faz o mesmo que git pull --rebase --autostash e depois faz push. A gravação continua; a edição de uma reunião fica em pausa nesse momento e avisa.

Quando os commits do remoto entram em conflito com os seus, o Earkeep entrega o rebase interrompido a um dos agentes ACP da sua máquina, como o Claude Code ou o Codex. Depois verifica o repositório, não a resposta do agente: o rebase terminou, os commits dos dois lados estão lá, não resta nenhum marcador de conflito. Só então faz push.

Tudo o que fique aquém disso é desfeito: o rebase é abortado, o seu ramo e as alterações por submeter voltam a ficar como estavam, e o Earkeep diz-lhe o que o agente respondeu. O agente é a sua própria ferramenta, com a sua própria chave, por isso o que ele lê vai para onde esse agente normalmente o envia.

Uma falha aparece acima da transcrição em palavras simples (o remoto recusou a sua chave, não foi possível contactar o anfitrião, um conflito precisa de si), com as palavras do próprio Git por baixo. O Earkeep tenta de novo de cinco em cinco minutos, por isso, assim que a causa estiver resolvida, o push é concluído.

• Privado por conceção: os ficheiros em que isto faz commit.
• Agentes e MCP: os agentes que escrevem as suas atas e resolvem os seus conflitos.
• PKM para programadores: notas como repositório Git.
• A wiki de LLM: no que se torna uma pasta de reuniões com versões.