Re: [PATCH v2] refs: run copy and rename through transactions

From: Maciej Ciemborowicz <maciej.ciemborowicz@gmail.com>
Date: Oct 2, 2026, 14:16 UTC
Message-ID: <CACQ=SRGSEsbNz3v3obd3JUOs2MrROnvuHkx1Dm51seCcv+12Cw@mail.gmail.com>
In-Reply-To: <ar-N7SA63fN_xx9P@pks.im>

On Fri, Oct 2, 2026 at 12:56 PM Patrick Steinhardt <ps@pks.im> wrote:

> Sorry, but what does this last sentence mean? What is the consequence
> of it?

The intent was to address Junio's comment about making copy/rename a property of the whole ref_transaction. In v2 the extra state is attached to the destination ref_update instead.

> why can't we make this whole mechanism completely agnostic of the
> backend and implement this via pure transactions?

The part I was trying to preserve is the existing reflog semantics. A normal ref transaction can express the logical ref updates. In example deleting the old ref and creating/updating the destination. But branch rename/copy also moves or copies the existing reflog history. For the files backend that currently involves filesystem-level reflog rename/copy and D/F handling, while reftable represents the same operation differently. So my assumption was that the logical ref updates could go through the generic transaction API, while the reflog-history operation would remain backend-specific.

> Is this new behaviour? Is this retaining old behaviour?

The source/destination revalidation is new validation required by introducing the preparing hook before the backend locks are taken. The hook can itself change one of the refs. Without revalidation, the hook payload could describe one state while the rename/copy later operates on another state. The intention is therefore to reject an operation when the state observed by the preparing hook is no longer the state being committed.

> How does all of this impact performance?

Enabling reference-transaction for rename/copy naturally adds the cost of invoking the hook when one is installed. I measured `git branch -m` and `git branch -c`. Each result is the median of five blocks of 40 commands per version:

                         Hook    Before     After     Change
files     branch -m       no      5.089 ms   5.234 ms   +3.8%
files     branch -m       yes    12.608 ms  11.134 ms  -10.8%
files     branch -c       no      4.753 ms   4.916 ms   +3.4%
files     branch -c       yes     5.509 ms  12.732 ms +137.7%
reftable  branch -m       no      6.478 ms   6.998 ms   +7.8%
reftable  branch -m       yes     5.918 ms  13.229 ms +114.6%
reftable  branch -c       no      5.620 ms   6.368 ms  +10.9%
reftable  branch -c       yes     6.261 ms  12.354 ms  +97.0%

Show 5 quoted lines

> Sorry, but I'm going to stop reading here. This is not in a state that
> is reviewable and has way too much stuff that is obviously generated by
> an AI without much thought being put into it by the author. I don't want
> to invest my time into a topic where the author has obviously not spent
> their time thinking about it, either.

I'm really sorry to hear that. Yes, the patches I prepared were AI-assisted, but I do feel that I understand what I am doing. I would appreciate some understanding, though, as I do not work with C on a daily basis. The bug report and my attempt to fix it came from the fact that I am working on a Ruby gem for per-branch and per-worktree containerization. That is why I had to write git-hooks-ext, which is how I ended up running into this bug in the first place.

I am not insisting that my patch should be merged. I simply thought that submitting a patch might help get the bug fixed faster, and getting the bug fixed is what I care about most. Karthik Nayak offered to help fix it, so perhaps it would be better for someone who works with C on a daily basis to take it over.

I can, of course, also prepare a v3, split it into more commits, and explain my reasoning more clearly. But I cannot guarantee that it will meet your standards, simply because I am not yet familiar with them.