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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html