totally agree. in principle, commit histories should be treated as immutable, especially on shared or production branches.

this tool is not meant to rewrite public history or alter real project timelines. it's more of a utility for personal or experimental repos (or branches), the kind of messy ones full of "update again" commits that never had a proper history. that's exactly why I built it.

There's actually a mechanism in Git to add notes to commits after the fact, unsurprisingly called notes

In the case of Git, the fact that they have a reasonable name is rather surprising.

huh TIL. Does GitHub show these notes in the UI?

only once pushed or merged to a shared branch.

They are. If you rewrite history, you get a different hash. You can do some shenanigans with git-replace, but those are usually for stitching history across gaps (like hooking pre-publish history to public release for internal archaeology at least.

What you actually want is a ban on rewriting tags or accepting branch updates to commits that do not have the current commit as an ancestor. These hooks do exist, but are not on by default (beyond the toilet paper protection of needing --force).

You also have to ban deleting branches because otherwise you just delete and push a new one with the same name. Maybe we should store topic branches in repos under refs/topics/ to distinguish integration branches from development/review branches?

Not sure I agree, I don't even remember how many times I have moved HEAD down.