Git cannot push to repository with too many tags/heads

["Stephen C. Tweedie" <sct@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