Re: [PATCH 1/1] Improve progress display in kB range.

It turns out that the off by one is intentional.

/* Data ready; we keep the last byte to ourselves
 * in case we detect broken rev-list, so that we
 * can leave the stream corrupted.  This is
 * unfortunate -- unpack-objects would happily
 * accept a valid packdata with trailing garbage,
 * so appending garbage after we pass all the
 * pack data is not good enough to signal
 * breakage to downstream.
 */

Upload-pack uses a buffer of 8193 octets, which is why it is always the second xread() that returns 0xFFF. It first sends 8191 octets, then n chunks of 8192 and then the final chunk.

It seems to only way to fix the progress annoyance -- and it is most annoying -- would be to round correctly in progress.c.

(The .99 comes from 1023/1024, which is .999 and therefor ought to round up to 1.00, not down to 0.99.)

Will a patch which does round-to-nearest (instead of the current round-to-zero) be accepted?

-JimC