The problem was reported by Mitja Bezenšek on GitLab's Git repo. Since 0e358de64a (fetch: use batched reference updates, 2025-05-19), git-fetch fetches regular references and backfills tags inside the same reference transaction. The first set of refs is therefore not on disk when tag backfilling starts. In shallow repositories the negotiation does not advertise the newly fetched refs. As Nayak describes it, the server can then send objects the client already has.
Nayak says earlier versions (1-3) fixed this by splitting the transaction in two. That worked but had drawbacks, and the current approach is different. The revised commit message says the issue always existed when --atomic was used, since the regular updates and the tags must share one transaction. The fix makes the backfill negotiation advertise the newly fetched refs.
The series also contains cleanup and test work. One patch adds transport_options_release(). transport.c cleared the data in git_transport_options on cleanup, but transport-helper.c did not, so memory leaked when remote helpers were used. The new tests expose that leak. Another patch adds a test that upstream tracking configuration is still written when one reference update in the batch is rejected.
Patrick Steinhardt said he is happy with the changes and asked for a point to be clarified in the commit message. Nayak said he would push a new version with the review fixes.