Bitácora

El amend que aplastó tres meses

Un commit lleva dos fechas. La de autor dice cuándo se escribió el trabajo; la de committer dice cuándo se hizo este objeto commit en concreto. Casi siempre…

Un commit lleva dos fechas. La de autor dice cuándo se escribió el trabajo; la de committer dice cuándo se hizo este objeto commit en concreto. Casi siempre son idénticas, que es justo por lo que nadie piensa en ellas — hasta que una operación reescribe un commit y tiene que decidir en qué se convierte cada una.

Hasta 0.11, torii save --amend ponía las dos a ahora.

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

Por qué es peor de lo que suena

Enmienda una vez y has movido un commit unos minutos. Nadie se entera. Pero amend es a lo que echas mano mientras limpias una rama antes de una revisión, y un rebase enmienda todos los commits que reproduce. Haz eso sobre una rama que llevó una temporada y todo llega al otro extremo sellado con la misma tarde.

Lo que se pierde no es decoración. La fecha de autor es el único registro del ritmo al que se construyó algo: si una función costó dos días o seis semanas, si un arreglo aterrizó antes o después del incidente al que se refiere, si dos commits que parecen contiguos estaban en realidad a un mes de distancia. git log --author-date-order deja de significar nada. Y no se recupera: la información estaba en el objeto que acabas de sustituir.

Qué hace ahora

La fecha de autor se preserva por defecto, igual que hace git commit --amend desde siempre, y solo se mueve la de committer — que es lo correcto, porque un objeto commit nuevo sí se ha hecho ahora mismo.

También se respetan GIT_AUTHOR_DATE y GIT_COMMITTER_DATE, en amend y en un save normal, que es lo que permite a un script o a una migración declarar las fechas en vez de heredar el reloj.

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 existe porque a veces sí quieres la identidad nueva y la hora nueva: has recogido la rama abandonada de otra persona, y fingir lo contrario sería su propia clase de mentira.

La misma decisión, en todo lo demás

Una vez lo has dicho en voz alta para amend, el resto de la superficie tiene que estar de acuerdo. Toda reescritura de torii history preserva por defecto las fechas de autor y de committer, redate existe para cuando quieres cambiarlas expresamente, y el pre-vuelo del motor se niega a correr con el árbol sucio para que la pregunta no llegue nunca a medio contestar.

La forma general: una herramienta que reescribe tu historia tiene que ser explícita sobre qué hechos se le permite inventar. El tiempo no es uno de ellos salvo que tú lo digas.

Una menor de la misma release

torii history rebase -i --todo-file degradaba en silencio una línea reword <sha> pelada a pick. El camino no interactivo documentado no podía, por tanto, reescribir ningún mensaje, que es un buen ejemplo de función que existe, está documentada y no funciona: ahora abre GIT_EDITOR, luego core.editor, luego EDITOR, y si no hay ninguno lo dice en vez de no hacer nada calladamente.