"Stephen C. Tweedie" <sct@xxxxxxxxxx> writes: > Adding more ^refs up to the limit of 900 should be possible, too, and > should catch more already-present objects --- while the refs count for > this repo was under 900, push still worked fine for me, so we don't > necessarily have to cut it hard to as low a number as 16. Actually it was done on purpose. My first round did not have that 16 limit, and then it turned out that rev-list, given extra work to cull those 900 negative refs, were spending a lot of time. I created a repository with 1500 tags for this test ;-). Unless we were talking about a repository that happens to host 1000 unrelated projects, each tracked with separate sets of heads and tags, those negative refs should be related with each other in the ancestry graph. We should be able to eliminate most of them by using the latest handful. > Perhaps ultimately we may want to simply send the refs list to > git-rev-list via a pipe or similar if we want this to scale? We'll need > this for edge cases such as sending >900 new tags to an old repository > at once, as we'll exhaust the size of the positive refs list in that > case. True. We should support unbounded number of positive refs. - : 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