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