On Thu, Mar 19, 2015 at 04:31:36PM -0400, Stephen Morton wrote: > > Hmm. The "push" process must feed the set of object boundaries to > > "pack-objects" so it knows what to pack (i.e., what we want to send, and > > what the other side has). > > > > 120,000 is an awfully large number of objects to be pass there, though. > > Does the repo you are pushing to by any chance have an extremely large > > number of refs (e.g., on the order of 120K tags)? > > No. There are on the order of 9,500 refs (mostly tags) but nowhere near 120k.
I think you mentioned that it uses alternates to share objects with other repos. Does the repository (or repositories) pointed to by the alternates file have a large number of refs (especially distinct refs, as I think modern git will squelch duplicate sha1s). > It did _not_ happen in a new clone --a push took just 5s -- and I > think the culprit could have been "repack.writebitmaps=true". Although > I had thought writebitmaps was not originally enabled, I now suspect > that it was. Let me follow up on that first, before I recompile git > with your changes. It's certainly possible that bitmaps have an impact here. They should not contribute to the 120K objects being passed to pack-objects, but it's possible that size is a red herring (or possibly the number of objects is choking something in the bitmap code path that does not have problems otherwise). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
