Què passa quan reescrius la història

Reescriure la història és l'operació que la gent agafa un cop cada dos anys, executa des d'un conjur de git filter-branch a mig recordar, i fa malament. La comanda resulta poc familiar precisament perquè és rara, i és destructiva precisament quan resulta poc familiar.

Des de 0.11 i 0.12 tota la superfície són subcomandes de primera classe de torii history, i totes són el mateix motor a sota: reword canvia missatges, reauthor canvia identitats, redate canvia dates, replace-text canvia contingut de fitxers, filter-path canvia quines rutes existeixen, i exec-filter executa el que vulguis contra cada arbre materialitzat.

Les quatre coses que passen abans de tocar cap commit

Es nega a arrencar amb l'arbre brut. Una reescriptura recorre i reconstrueix cada commit del rang; fer-ho amb feina sense commitejar pel mig vol dir que aquesta feina no és ni a la història vella ni a la nova. El pre-vol també es nega quan hi ha una operació pendent —un rebase a mitges, un cherry-pick esperant un conflicte— perquè la reescriptura es construiria sobre un estat que encara estàs decidint.

Pren un snapshot. Ni un commit ni un stash: un desat local de l'arbre de treball, restaurable per id, que no entra mai a la teva història i no arriba mai a un remot. Aquesta és tota la diferència entre «la reescriptura ha sortit malament» i «la reescriptura ha sortit malament i he perdut la tarda».

torii snapshot list
torii snapshot restore <id>

Preserva les dates. Les dates d'autor i de committer sobreviuen per defecte. Sona a detall fins que has vist un filter-branch aixafar sis mesos d'història en «tot commitejat fa trenta segons», i amb això cada senyal sobre com va créixer el projecte de debò.

Reescriu l'arbre i després mou les refs. Els commits es reconstrueixen primer i les referències s'apunten a la història nova després, així que una reescriptura interrompuda deixa les refs velles intactes en comptes de a mig moure.

El que deliberadament no amaga

Dues consequències són inherents a reescriure la història, i fingir el contrari seria pitjor que dir-les:

Les signatures no sobreviuen. Una signatura GPG signa un objecte commit. Reescriure produeix un objecte diferent, així que la signatura ja no verifica — no es retira per cortesia, simplement ha deixat de ser certa. torii sign torna a signar la història nova quan la vulguis de tornada.

El següent push és forçat. Els altres continuen tenint la història vella. En una branca compartida això és una conversa que cal tenir abans de la reescriptura, no després: torii sync --force fa el que diu, i el que diu és que guanya la teva versió.

La que més importa

torii history replace-text --redact-secrets

Redacta totes les línies que l'escàner marca, a cada fitxer de cada commit. És la manera més ràpida de netejar un repositori després de commitejar una clau — i no fa que la clau sigui segura. La clau va ser pública en el moment del push; rota-la primer, i neteja la història després perquè qui cloni a continuació no la trobi. L'ordre no és negociable i l'eina no el pot imposar per tu.

Previsualitzar

Totes accepten --dry-run, i --since <ref> per acotar el rang. En un repositori on la història importa, la seqüència que no ha fallat mai a ningú és: assaig en sec, llegir la sortida, snapshot, executar-ho, comprovar torii log, i només llavors el push forçat.