On Thu, Mar 13, 2014 at 2:26 PM, Jeff King <p...@peff.net> wrote: > On Wed, Mar 12, 2014 at 05:21:21PM -0700, Shawn Pearce wrote: > >> Today I tried pushing a copy of linux.git from a client that had >> bitmaps into a JGit server. The client stalled for a long time with no >> progress, because it reused the existing pack. No progress appeared >> while it was sending the existing file on the wire: >> >> $ git push git://localhost/linux.git master >> Reusing existing pack: 2938117, done. >> Total 2938117 (delta 0), reused 0 (delta 0) >> remote: Resolving deltas: 66% (1637269/2455727) >> >> This is not the best user experience. :-( > > Yeah, I agree that sucks. I hadn't noticed it, as I don't typically have > my client repos bitmapped (and on fetch, the interesting progress is > coming from the local index-pack). > > It would definitely be good to have throughput measurements while > writing out the pack. However, I'm not sure we have anything useful to > count. We know the total number of objects we're reusing, but we're not > actually parsing the data; we're just blitting it out as a stream. I > think the progress code will need some refactoring to handle a > throughput-only case.
Yes. I think JGit suffers from this same bug, and again we never noticed it because usually only the servers are bitmapped, not the clients. pack-objects writes a throughput meter when its writing objects. Really just the bytes out/second would be enough to let the user know the client is working. Unfortunately I think that is still tied to the overall progress system having some other counter? -- 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
