Quadern

L'amend que va aixafar tres mesos

Un commit porta dues dates. La d'autor diu quan es va escriure la feina; la de committer diu quan es va fer aquest objecte commit en concret. Gairebé sempre…

Un commit porta dues dates. La d'autor diu quan es va escriure la feina; la de committer diu quan es va fer aquest objecte commit en concret. Gairebé sempre són idèntiques, que és justament per això que ningú hi pensa — fins que una operació reescriu un commit i ha de decidir en què es converteix cadascuna.

Fins a 0.11, torii save --amend posava totes dues a ara.

before 0.11 — torii save --amend march april may all "30 seconds ago" three months, flattened 0.11 onwards march april may author date preserved only the committer date moves GIT_AUTHOR_DATE and GIT_COMMITTER_DATE are honoured · --keep-date pins both

Per què és pitjor del que sembla

Esmena una vegada i has mogut un commit uns minuts. Ningú se n'assabenta. Però amend és el que agafes mentre neteges una branca abans d'una revisió, i un rebase esmena tots els commits que reprodueix. Fes això sobre una branca que va durar una temporada i tot arriba a l'altre extrem segellat amb la mateixa tarda.

El que es perd no és decoració. La data d'autor és l'únic registre del ritme al qual es va construir una cosa: si una funció va costar dos dies o sis setmanes, si un arranjament va aterrar abans o després de l'incident al qual es refereix, si dos commits que semblen contigus eren en realitat a un mes de distància. git log --author-date-order deixa de significar res. I no es recupera: la informació era a l'objecte que acabes de substituir.

Què fa ara

La data d'autor es preserva per defecte, igual que fa git commit --amend de sempre, i només es mou la de committer — que és el correcte, perquè un objecte commit nou sí que s'ha fet ara mateix.

També es respecten GIT_AUTHOR_DATE i GIT_COMMITTER_DATE, en amend i en un save normal, que és el que permet a un script o a una migració declarar les dates en comptes d'heretar el rellotge.

torii save --date "2026-03-14T09:12:00+01:00"     # set the author date
torii save --amend --keep-date                    # pin the committer date to it
torii save --amend --reset-author                 # deliberately take both as now

--reset-author existeix perquè de vegades sí que vols la identitat nova i l'hora nova: has recollit la branca abandonada d'una altra persona, i fingir el contrari seria la seva pròpia mena de mentida.

La mateixa decisió, a tota la resta

Un cop ho has dit en veu alta per a amend, la resta de la superfície hi ha d'estar d'acord. Tota reescriptura de torii history preserva per defecte les dates d'autor i de committer, redate existeix per quan les vols canviar expressament, i el pre-vol del motor es nega a córrer amb l'arbre brut perquè la pregunta no arribi mai a mig contestar.

La forma general: una eina que reescriu la teva història ha de ser explícita sobre quins fets se li permet inventar. El temps no és un d'ells tret que ho diguis tu.

Una de menor de la mateixa release

torii history rebase -i --todo-file degradava en silenci una línia reword <sha> pelada a pick. El camí no interactiu documentat no podia, per tant, reescriure cap missatge, que és un bon exemple de funció que existeix, està documentada i no funciona: ara obre GIT_EDITOR, després core.editor, després EDITOR, i si no n'hi ha cap ho diu en comptes de no fer res calladament.