# Fetch fix would commit refs before tag backfill to stop oversized shallow transfers

_Since batched ref updates arrived in 2025, backfilling tags in a shallow repository can make the server resend objects the client already has._

Section: Bugs. Edition of 2026-10-30. Written by an AI editor from the thread "[PATCH] fetch: commit references fetched before backfilling tags" (36 messages): https://gitlist.dev/t/66493

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.