On Tue, 21 Apr 2009, James Cloos wrote: > >>>>> "Nicolas" == Nicolas Pitre <nico@xxxxxxx> writes: > > Nicolas> On Sun, 19 Apr 2009, James Cloos wrote: > >> When progress.c:throughput_string() is called, the variable total > >> invariably has its twelve least significant bits set. Ie, it is > >> always the case that: > >> > >> total & 0xFFF == 0xFFF > > Nicolas> Could you please explain ow you come to that conclusion? > > Empirical evidence. > > Even since the current progress was added, it has always shown nn.99 KiB > in that range. I added an extra snprintf(3) to show total in hex and it > always ends in FFF. Empirical evidence on my side shows the opposite. I just did a fetch in my kernel repo and got: Receiving objects: 100% (1373/1373), 223.36 KiB, done. > I presume the progress function is getting called just before total hits > a page boundry. In any case, the empirical evidence is clear. And only > even seeing .99 is annoying. Hense the proposed patch. I must NACK your patches. Presumptions are not good enough justification for such a change, especially if results can't be reproduced. That doesn't mean the code is completely bug free of course, but finding the source of the bug affecting you would be a far better course of action than simply turning our back on it. Maybe you can tell us more about your environment? Nicolas -- 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