On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano <gits...@pobox.com> wrote: > Antoine Pelisse <apeli...@gmail.com> writes: > >> Currently, humanization of downloaded size is done in the same >> function as text formatting in 'process.c'. This is an issue if anyone >> else wants to use this. >> >> Separate text formatting from size simplification and make the function >> public in strbuf so that it can easily be used by other clients. >> >> We now can use strbuf_humanize() for both downloaded size and download >> speed calculation. One of the drawbacks is that speed will now look like >> this when download is stalled: "0 bytes/s" instead of "0 KiB/s". > > Personally, I do not think the "drawback" is so big an issue. If > the caller really cares, we could always add another parameter to > this formatter to tell it the minimum unit we care about (e.g. pass > 1024 to say "Don't bother showing scale lower than kibi").
I thought about that, but decided it was not worth it (at least for the moment) > This is a bit late response, but if we ever want to count something > in a dimention other than "bytes", like time (e.g. "kiloseconds") or > number of commits (e.g. "centicommits"), etc., we cannot reuse this > formatter very easily. We may want to have "byte" somewhere in its > name for now to make sure the callers understand its limitation. I'm not in a hurry. But it look tough to make it generic: one is binary, another is sexagesimal, and the last is decimal > I'll tentatively rename it to "strbuf_humanize_bytes()" while queuing. I like the idea, Thanks, -- 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