Log

The amend that flattened three months

A commit carries two dates. The author date says when the work was written; the committer date says when this particular commit object was made. Most of the…

A commit carries two dates. The author date says when the work was written; the committer date says when this particular commit object was made. Most of the time they are identical, which is exactly why nobody thinks about them — until an operation rewrites a commit and has to decide what each one becomes.

Until 0.11, torii save --amend set both to now.

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

Why that is worse than it sounds

Amend once and you have shifted one commit by a few minutes. Nobody notices. But amend is what you reach for while cleaning a branch before review, and a rebase amends every commit it replays. Do that over a branch that took a season and the whole thing arrives at the far end stamped with the same afternoon.

What is lost is not decoration. The author date is the only record of the pace at which something was built: whether a feature took two days or six weeks, whether a fix landed before or after the incident it refers to, whether two commits that look adjacent were actually a month apart. git log --author-date-order stops meaning anything. And it is not recoverable — the information was in the object you just replaced.

What it does now

The author date is preserved by default, matching what git commit --amend has always done, and only the committer date moves — which is correct, because a new commit object genuinely was made just now.

GIT_AUTHOR_DATE and GIT_COMMITTER_DATE are honoured too, on amend and on a plain save, which is what lets a script or a migration state the dates rather than inherit the clock.

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 exists because sometimes you do want the new identity and the new time: you have taken over someone's abandoned branch, and pretending otherwise would be its own kind of lie.

The same decision, everywhere else

Once you have said it out loud for amend, the rest of the surface has to agree. Every torii history rewrite preserves author and committer dates by default, redate exists for when you specifically want to change them, and the rewrite engine's pre-flight refuses to run on a dirty tree so the question never arrives half-answered.

The general shape: a tool that rewrites your history has to be explicit about which facts it is allowed to invent. Time is not one of them unless you say so.

A smaller one from the same release

torii history rebase -i --todo-file silently downgraded a bare reword <sha> line to pick. The documented non-interactive path could therefore not reword anything, which is a fine example of a feature that exists, is documented, and does not work: it now opens GIT_EDITOR, then core.editor, then EDITOR, and if none is set it says so rather than quietly doing nothing.