Re: Git cannot push to repository with too many tags/heads

From: Junio C Hamano <junkio@cox.net>
Date: Feb 22, 2006, 01:59 UTC
Message-ID: <7vwtfotaq3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1140547568.5509.21.camel@orbit.scot.redhat.com>

"Stephen C. Tweedie" <sct@redhat.com> writes:

Show 11 quoted lines

> 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.

IIRC, the distinction was deliberate. send_pack() excludes what did not match because it does not want to send them. rev_list() adds what we know they have to "do not bother to send" list to make the resulting pack smaller. The time where it matters most is when you are pushing a new branch head (or a tag).

I think the exec_rev_list logic should be taught to first include all the positive refs (i.e. the ones we are going to send), and then as many the negative refs (i.e. the ones we know they have), from newer to older, as they fit without triggering "argument list too long".

Another, probably conceptually cleaner alternative might be to allow rev-list to read from its stdin so that we do not have to worry about the argument list issues.