Re: No progress from push when using bitmaps

From: Shawn Pearce <spearce@spearce.org>
Date: Mar 13, 2014, 22:01 UTC
Message-ID: <CAJo=hJu1WscibwectWzrUcoOV4-9xk4hBm1JA+RjONmgvZTXwQ@mail.gmail.com>
In-Reply-To: <20140313212626.GA23618@sigill.intra.peff.net>

On Thu, Mar 13, 2014 at 2:26 PM, Jeff King <peff@peff.net> wrote:

Show 24 quoted lines

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