It turns out that the off by one is intentional. >From upload-pack.c: /* 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 -- James Cloos <cloos@xxxxxxxxxxx> OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html