Re: [BUG] branch copy/rename update refs without running the reference-transaction hook
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Oct 2, 2026, 19:37 UTC
- Message-ID
- <asAIAHC_zuHPLljW@fruit.crustytoothpaste.net>
- In-Reply-To
- <CAPHjog3wuWOdZS3pHQd20hdZNwA5iXsQMkEfmSnp=NGhLBzuJg@mail.gmail.com>
On 2026-10-02 at 04:12:55, Никита Поникаров wrote:
> Hi,
Hi,
Show 26 quoted lines
> githooks(5) says the reference-transaction hook "is invoked by any Git
> command that performs reference updates". Some branch copy and rename
> operations update a ref without invoking it.
>
> Observed on git version 2.55.0.windows.5, with the hook registered both
> in .git/hooks and as a config-defined hook (hook.<name>.event).
>
> 1. `git branch -C <src> <dst>` where <dst> exists and is not checked out
> anywhere: <dst> is overwritten with <src>'s value and the hook is not
> invoked in any phase. This happens on both the files and the reftable
> backend. With every documented hook event registered to a logging
> script, none of them fired, and a GIT_TRACE2_EVENT log showed no child
> process.
>
> 2. `git branch -c <src> <dst>` where <dst> does not exist: <dst> is
> created and the hook sees no line for it.
>
> 3. `git branch -m/-M <src> <dst>`:
> - files backend: the hook sees the deletion of <src> and a
> "0000... 0000... refs/heads/<dst>" line, but no line carrying
> <dst>'s new value;
> - reftable backend: no line names <dst> at all, and renaming a branch
> away deletes it without a line for it.
>
> 4. `git reflog delete --updateref --rewrite <branch>@{0}` rewinds the
> branch without invoking the hook, on both backends.I think there was a recent thread about this at https://lore.kernel.org/git/CACQ=SRHCOCcmVCgHqd+sjMsZ9LCdSHuXdCo0gkwxXwYgF7iwig@mail.gmail.com/
There were some patches, but they appeared AI generated and were not picked up. Perhaps you or someone else could send in some higher-quality patches not using AI (see Documentation/SubmittingPatches) that could fix the issue.
I will say that using reference transactions to solve this problem would be very desirable from a variety of perspectives, especially since it would probably go a long way to unlocking way better performance for `git remote rename` with many remote-tracking branches as well.
-- brian m. carlson (they/them) Toronto, Ontario, CA