git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Git cannot push to repository with too many tags/heads

From
STStephen C. Tweedie <sct@redhat.com>
Date
Feb 21, 2006, 18:46 UTC
Message-ID
<1140547568.5509.21.camel@orbit.scot.redhat.com>
Hi,

I'm using git's cvs import to track the Fedora kernel rpm repository, and it has just passed a watermark that git cannot currently cope with.

The problem is the large number of branches and tags on this repository. A tag for every build means that the number builds up rapidly, and git-send-pack has an internal limit of 900 refs to query when building a pack.

I hoped this wouldn't be a problem. In theory, I should just be able to push to a single refspec and avoid that limit entirely. But no --- unfortunately, git is determined to push out the objects for *every* ref that matches between src and dst when building the pack, even if it's not actually going to update the remote ref. And in building the git-rev-list argument list for that colossal update, it exceeds the internal limit of 900 refs in exec_rev_list().

I think exec_rev_list() is doing the wrong thing here. If I specify an explicit refspec list for git-send-pack, then when send_pack() calls match_refs(), we break out to match_explicit_refs() and set dst->peer_ref only for the ref[s] which match the refspec. send_pack() then skips all other refs by doing a

		if (!ref->peer_ref)
			continue;

Unfortunately, exec_rev_list() is missing this, and it tries to ask git-rev-list for the commit objects of *every* ref on the remote_refs list, even if they have been explicitly excluded by match_refs() and have no peer_ref. So with this huge repository, I can't even push a single refspec without bumping into the limit of 900 refs.

The immediate consequence to me is that I can't push to this particular repository. But if I'm following the code right, a consequence is that git-send-pack is accidentally sending all objects for refs that the remote end is prepared to receive, even if we've supplied a refspec asking for only a subset of those refs to actually be updated.

I think we can fix this just by adding a test for ref->peer_ref to exec_rev_list(). That seems to fix the immediate problem for me, at least. Patch to follow.

--Stephen
Next: Stephen C. Tweedie
Message 1 of 7 in “Git cannot push to repository with too many tags/heads”
  1. Stephen C. TweedieFeb 21, 2006
  2. Don't sent objects for refs we're not going to update.Stephen C. Tweedie, Feb 21, 2006
  3. Junio C HamanoFeb 22, 2006
  4. Junio C HamanoFeb 22, 2006
  5. send-pack: do not give up when remote has insanely large number of refs.Junio C Hamano, Feb 22, 2006
  6. Stephen C. TweedieFeb 22, 2006
  7. Junio C HamanoFeb 22, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.