Git branch rename skips half the reference-transaction hook
A fix routes branch copy and rename through ordinary ref transactions so hooks finally see both endpoints on files and reftable backends.
Git's reference-transaction hook has long mishandled git branch -m and git branch -c. A rename logically deletes the old branch ref and creates the new one in one step, yet the hook never saw a complete picture of that change.
On the classic files backend the hook reported only the source deletion. On reftable it reported nothing useful. The same logical update performed through git update-ref --stdin already exposed both ends correctly, so tooling that relies on the hook for auditing, access control, or external indexers could miss renames and copies entirely while still trusting other ref updates.
Maciej Ciemborowicz reported the gap against current Git and sent a series that folds copy and rename into the ordinary transaction path. Both backends now queue the source deletion and destination creation together, and they replay the source reflog history through the transaction API so the hook observes one coherent operation it can accept or reject. Nested packed-refs work is marked internal so callers are not spammed with duplicate events. Backend-specific rename callbacks are removed once the generic path covers the same ground.
Review from Patrick Steinhardt and Junio C Hamano pushed the design away from special-case transaction flags and toward reusing the reflog-writing machinery already used for backend migration, plus a new replace-reflog primitive so destination history can be discarded cleanly before the copied entries are installed. Preparing-hook revalidation of pre-lock snapshots was dropped after debate: the preparing stage is documented as running before locks, so later prepared and committed payloads simply report values read under lock.
The cost is intentional. Replaying reflog history is linear in the number of entries. Short histories stay near existing timings; a local benchmark with ten thousand entries showed files renames rising from roughly 5 ms to 17 ms and reftable from 44 ms to 54 ms when no hook is installed. That trades the old constant-time files rename for staging that never exposes a half-applied rename to a prepared hook.
Anyone wiring automation to reference-transaction can now treat branch renames and copies like any other atomic ref update, on either storage backend.