From: Petr Baudis <pasky@suse.cz>
To: Marcus Griep <marcus@griep.us>
Cc: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 2] count-objects: add human-readable size option
Date: Thu, 14 Aug 2008 18:34:46 +0200 [thread overview]
Message-ID: <20080814163446.GD10360@machine.or.cz> (raw)
In-Reply-To: <48A45CC9.5040708@griep.us>
On Thu, Aug 14, 2008 at 12:26:49PM -0400, Marcus Griep wrote:
> Petr Baudis wrote:
> > Are you aware of progress.c:throughput_string()? It would make sense to
> > use the same code in both instances.
>
> I was not. After reviewing it, it is limited to its purposes, but
> consolidating the human-readable-ness is a good idea.
Of course, it would need an usage overhaul. But otherwise, it seems
fine? Terabyte-sized objects in Git would be very troublesome venture
for many reasons.
> (who's got transfer speeds in TiB/s?)
Maybe Dana Brown? ;-)
> > I'd prefer you to keep using binary units instead of the ambiguous
> > prefixes, since we should keep our output consistent and I believe they
> > usually end up to be the least confusing choice. (Otherwise, don't you
> > want to use "bkM" instead of "BKM"? I never really know.)
>
> In general, "b" would be supplied as a part of the suffix, so that is no
> longer in the prefix list. The distinction comes with kilo vs. kibi. In
> an earlier email reply, I mentioned a flag to denote SI versus binary
> periods. In common nomenclature, Kilo (1000) is designated 'k', while
> Kibi (1024) is designated 'K' (the 'i' after the 'K' is supplied by the
> suffix if desired). Thus, if the user wants binary, they'll get the capital
> 'K', and if they want SI, they'll get the lowercase 'k'.
>
> Sound reasonable?
I'm confused - you didn't seem to really address my suggestion. Is there
a good reason _not_ to go with the /.iB/ prefixes, and just forget about
SI? Who is ever going to need SI?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
next prev parent reply other threads:[~2008-08-14 16:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 20:05 [PATCH] count-objects: Add total pack size to verbose output Marcus Griep
2008-08-14 4:21 ` [PATCH 2] count-objects: add human-readable size option Marcus Griep
2008-08-14 4:38 ` Shawn O. Pearce
2008-08-14 4:44 ` Marcus Griep
2008-08-14 5:22 ` Junio C Hamano
2008-08-14 14:05 ` Johannes Schindelin
2008-08-14 14:26 ` Marcus Griep
2008-08-14 6:45 ` Alex Riesen
2008-08-14 14:03 ` Marcus Griep
2008-08-14 18:51 ` Alex Riesen
2008-08-15 9:22 ` Pierre Habouzit
2008-08-18 17:28 ` Alex Riesen
2008-08-14 7:39 ` Johannes Sixt
2008-08-14 14:09 ` Marcus Griep
2008-08-14 15:14 ` Petr Baudis
2008-08-14 16:26 ` Marcus Griep
2008-08-14 16:34 ` Petr Baudis [this message]
2008-08-14 16:42 ` Marcus Griep
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080814163446.GD10360@machine.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marcus@griep.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).