{"thread":{"id":"14990","subject":"[PATCH] count-objects: Add total pack size to verbose output","startedAt":"2008-08-13T20:05:10Z","lastAt":"2008-08-18T17:28:22Z","messageCount":18,"participants":["Marcus Griep","Shawn O. Pearce","Junio C Hamano","Alex Riesen","Johannes Sixt","Johannes Schindelin","Petr Baudis","Pierre Habouzit"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"87093","messageId":"1218657910-22096-1-git-send-email-marcus@griep.us","threadId":"14990","inReplyTo":null,"subject":"[PATCH] count-objects: Add total pack size to verbose output","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-13T20:05:10Z","receivedAt":"2008-08-13T20:05:10Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Adds the total pack size (including indexes) the verbose count-objects\noutput, floored to the nearest kilobyte.\n\nSigned-off-by: Marcus Griep <marcus@griep.us>\n---\n\n I used the pack size including the size of the associated indexes in\n computing total pack size since it more closely represents the disk\n usage of each pack. If separate reporting is preferred, they can be\n split apart.\n\n builtin-count-objects.c |    3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-count-objects.c b/builtin-count-objects.c\nindex 91b5487..249040b 100644\n--- a/builtin-count-objects.c\n+++ b/builtin-count-objects.c\n@@ -104,6 +104,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)\n \tif (verbose) {\n \t\tstruct packed_git *p;\n \t\tunsigned long num_pack = 0;\n+\t\tunsigned long size_pack = 0;\n \t\tif (!packed_git)\n \t\t\tprepare_packed_git();\n \t\tfor (p = packed_git; p; p = p->next) {\n@@ -112,12 +113,14 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)\n \t\t\tif (open_pack_index(p))\n \t\t\t\tcontinue;\n \t\t\tpacked += p->num_objects;\n+\t\t\tsize_pack += p->pack_size + p->index_size;\n \t\t\tnum_pack++;\n \t\t}\n \t\tprintf(\"count: %lu\\n\", loose);\n \t\tprintf(\"size: %lu\\n\", loose_size / 2);\n \t\tprintf(\"in-pack: %lu\\n\", packed);\n \t\tprintf(\"packs: %lu\\n\", num_pack);\n+\t\tprintf(\"size-pack: %lu\\n\", size_pack / 1024);\n \t\tprintf(\"prune-packable: %lu\\n\", packed_loose);\n \t\tprintf(\"garbage: %lu\\n\", garbage);\n \t}\n-- \n1.6.0.rc2.6.g8eda3\n"},{"id":"87144","messageId":"1218687684-11671-1-git-send-email-marcus@griep.us","threadId":"14990","inReplyTo":"1218657910-22096-1-git-send-email-marcus@griep.us","subject":"[PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T04:21:24Z","receivedAt":"2008-08-14T04:21:24Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Adds a human readable size option to the verbose output\nof count-objects for loose and pack object size totals.\n\nUpdates documentation to match.\n\nSigned-off-by: Marcus Griep <marcus@griep.us>\n---\n\n I thought that this would be a nice addition to 'git count-objects'.\n This patch depends upon my earlier patch to count-objects, but this\n patch should be easily separable from its dependency should that one\n not be accepted.\n\n Documentation/git-count-objects.txt |   13 +++++++---\n builtin-count-objects.c             |   41 +++++++++++++++++++++++++++++++---\n 2 files changed, 46 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt\nindex 75a8da1..291bc5e 100644\n--- a/Documentation/git-count-objects.txt\n+++ b/Documentation/git-count-objects.txt\n@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption\n \n SYNOPSIS\n --------\n-'git count-objects' [-v]\n+'git count-objects' [-v [-H]]\n \n DESCRIPTION\n -----------\n@@ -21,9 +21,14 @@ OPTIONS\n --verbose::\n \tIn addition to the number of loose objects and disk\n \tspace consumed, it reports the number of in-pack\n-\tobjects, number of packs, and number of objects that can be\n-\tremoved by running `git prune-packed`.\n-\n+\tobjects, number of packs, disk space consumed by those packs\n+\tand number of objects that can be removed by running\n+\t`git prune-packed`.\n+\n+-H::\n+--human-sizes::\n+\tDisplays sizes reported by `--verbose` in a more\n+\thuman-readable format. (e.g. 22M or 1.5G)\n \n Author\n ------\ndiff --git a/builtin-count-objects.c b/builtin-count-objects.c\nindex 249040b..1eb73be 100644\n--- a/builtin-count-objects.c\n+++ b/builtin-count-objects.c\n@@ -67,13 +67,30 @@ static void count_objects(DIR *d, char *path, int len, int verbose,\n }\n \n static char const * const count_objects_usage[] = {\n-\t\"git count-objects [-v]\",\n+\t\"git count-objects [-v [-H]]\",\n \tNULL\n };\n \n+void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n+{\n+\tchar human_readable_prefixes[10] = \"BKMGTPEZY\";\n+\tif (buf_size < 5)\n+\t\tdie(\"insufficient buffer size\");\n+\tint i = 0;\n+\tfor (; i < 8 && size >= 1000 ; ++i, size = size / 1024)\n+\t\t;\n+\tif (size >= 1000)\n+\t\tdie(\"size greater than 999Y\");\n+\tsprintf(buf, \"%.*f%c\",\n+\t\tsize < 10 ? 1 : 0,\n+\t\tsize,\n+\t\thuman_readable_prefixes[i]\n+\t\t);\n+}\n+\n int cmd_count_objects(int argc, const char **argv, const char *prefix)\n {\n-\tint i, verbose = 0;\n+\tint i, verbose = 0, human_readable = 0;\n \tconst char *objdir = get_object_directory();\n \tint len = strlen(objdir);\n \tchar *path = xmalloc(len + 50);\n@@ -81,6 +98,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)\n \tunsigned long loose_size = 0;\n \tstruct option opts[] = {\n \t\tOPT__VERBOSE(&verbose),\n+\t\tOPT_BOOLEAN('H', \"--human-sizes\", &human_readable,\n+\t\t\t\"displays sizes in human readable format\"),\n \t\tOPT_END(),\n \t};\n \n@@ -117,10 +136,24 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)\n \t\t\tnum_pack++;\n \t\t}\n \t\tprintf(\"count: %lu\\n\", loose);\n-\t\tprintf(\"size: %lu\\n\", loose_size / 2);\n+\t\tprintf(\"size: \");\n+\t\tif (human_readable) {\n+\t\t\tchar buf[sizeof(\"999Y\")];\n+\t\t\thuman_readable_size(buf, sizeof(buf), loose_size * 512);\n+\t\t\tprintf(\"%s\\n\", buf);\n+\t\t}\n+\t\telse\n+\t\t\tprintf(\"%lu\\n\", loose_size / 2);\n \t\tprintf(\"in-pack: %lu\\n\", packed);\n \t\tprintf(\"packs: %lu\\n\", num_pack);\n-\t\tprintf(\"size-pack: %lu\\n\", size_pack / 1024);\n+\t\tprintf(\"size-pack: \");\n+\t\tif (human_readable) {\n+\t\t\tchar buf[sizeof(\"999Y\")];\n+\t\t\thuman_readable_size(buf, sizeof(buf), size_pack);\n+\t\t\tprintf(\"%s\\n\", buf);\n+\t\t}\n+\t\telse\n+\t\t\tprintf(\"%lu\\n\", size_pack / 1024);\n \t\tprintf(\"prune-packable: %lu\\n\", packed_loose);\n \t\tprintf(\"garbage: %lu\\n\", garbage);\n \t}\n-- \n1.6.0.rc2.6.g8eda3\n"},{"id":"87145","messageId":"20080814043817.GC11232@spearce.org","threadId":"14990","inReplyTo":"1218687684-11671-1-git-send-email-marcus@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-14T04:38:17Z","receivedAt":"2008-08-14T04:38:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marcus Griep <marcus@griep.us> wrote:\n> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt\n> index 75a8da1..291bc5e 100644\n> --- a/Documentation/git-count-objects.txt\n> +++ b/Documentation/git-count-objects.txt\n> +++ b/builtin-count-objects.c\n...\n> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n\nHmm.  This probably should be static.  Or if it really is meant\nto be a utility for use elsewhere in Git, moved to someplace where\nstring handling is done.  Its not strbuf related, but maybe strbuf.c\nis a better location for this sort of library function.\n\nIf you do move this to strbuf.c, how about having it take a strbuf\nin and appending the formatted text onto it?  You'll neer have to\nworry about the buffer being too small and it fits into the whole\nstrbuf.c module thing.\n\nIf you keep this static here in builtin-count-objects.c, how about\nmaking the char *buf static scoped to the function, so you don't\nneed to pass the buffer, its size, nor check its size?\n\n> +{\n> +\tchar human_readable_prefixes[10] = \"BKMGTPEZY\";\n> +\tif (buf_size < 5)\n> +\t\tdie(\"insufficient buffer size\");\n> +\tint i = 0;\n\nWe don't declare variables after statements.  Please declare all\nvariables at the start of the block as not all compilers we support\nsupport this C99 syntax.\n\nOh, and welcome to Git.  I saw your SVN patches.  Glad to see\nyou hacking.  ;-)\n\n> +\tfor (; i < 8 && size >= 1000 ; ++i, size = size / 1024)\n> +\t\t;\n> +\tif (size >= 1000)\n> +\t\tdie(\"size greater than 999Y\");\n> +\tsprintf(buf, \"%.*f%c\",\n> +\t\tsize < 10 ? 1 : 0,\n> +\t\tsize,\n> +\t\thuman_readable_prefixes[i]\n> +\t\t);\n> +}\n> +\n\n-- \nShawn.\n"},{"id":"87146","messageId":"48A3B81B.10804@griep.us","threadId":"14990","inReplyTo":"20080814043817.GC11232@spearce.org","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T04:44:11Z","receivedAt":"2008-08-14T04:44:11Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Hmm.  This probably should be static.  Or if it really is meant\n> to be a utility for use elsewhere in Git, moved to someplace where\n> string handling is done.  Its not strbuf related, but maybe strbuf.c\n> is a better location for this sort of library function.\n> \n> If you do move this to strbuf.c, how about having it take a strbuf\n> in and appending the formatted text onto it?  You'll neer have to\n> worry about the buffer being too small and it fits into the whole\n> strbuf.c module thing.\n> \n> If you keep this static here in builtin-count-objects.c, how about\n> making the char *buf static scoped to the function, so you don't\n> need to pass the buffer, its size, nor check its size?\n\nI'll take this into account.  Though I didn't plan it to be a\ncross-git utility function, it probably could be, so I'll look\nat putting it in strbuf.c.\n\n> We don't declare variables after statements.  Please declare all\n> variables at the start of the block as not all compilers we support\n> support this C99 syntax.\n\nThis is the first time I've hacked on vanilla-C in about 5 years,\nso I'm quite rusty.  Much less my first time hacking on perl, ever,\nin the case of git-svn.  Thanks for the pointers.\n\n> Oh, and welcome to Git.  I saw your SVN patches.  Glad to see\n> you hacking.  ;-)\n\nGlad to be a part.\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87149","messageId":"7vskt8f9x2.fsf@gitster.siamese.dyndns.org","threadId":"14990","inReplyTo":"20080814043817.GC11232@spearce.org","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-14T05:22:17Z","receivedAt":"2008-08-14T05:22:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Marcus Griep <marcus@griep.us> wrote:\n>> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt\n>> index 75a8da1..291bc5e 100644\n>> --- a/Documentation/git-count-objects.txt\n>> +++ b/Documentation/git-count-objects.txt\n>> +++ b/builtin-count-objects.c\n> ...\n>> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n>\n> Hmm.  This probably should be static.  Or if it really is meant\n> to be a utility for use elsewhere in Git, moved to someplace where\n> string handling is done.  Its not strbuf related, but maybe strbuf.c\n> is a better location for this sort of library function.\n\nYes, with customizable precision (so that the caller can control \"1.6k\" vs\n\"1.62k\"), and perhaps cutomizable unit (so that you can use this for\n\"3.6kB\" and \"2.6Mbps\"), this kind of thing is a good candidate to be a\nlibrary function in strbuf.c.\n\n>> +{\n>> +\tchar human_readable_prefixes[10] = \"BKMGTPEZY\";\n\nThis enumerates suffix if I am not mistaken.  Do you have to say \"10\"\nhere, or does the compiler counts them for you?\n\n>> +\tfor (; i < 8 && size >= 1000 ; ++i, size = size / 1024)\n>> +\t\t;\n\nI do not think you would need to use the magic number \"8\" here.\n\nI have this suspicion that the caller, if this is made into a generic\nlibrary, would want to pass in a list of units, not magnitude suffixes,\nlike this:\n\n    extern int human_readable(struct strbuf *,\n    \t\t\t      double value, int precision,\n                              const char **unit);\n\n    static const char **size_unit = {\n    \t\"byte\", \"KB\", \"MB\", \"GB\", NULL,\n    };\n    static const char **throughput_unit = {\n    \t\"bps\", \"Kbps\", \"Mbps\", \"Gbps\", NULL,\n    };\n\n    human_readble(&sb, (double) bytes_transferred, 0, size_unit);\n    human_readble(&sb, (double) throughput, 2, throughput_unit);\n"},{"id":"87160","messageId":"20080814064524.GA4379@blimp.local","threadId":"14990","inReplyTo":"1218687684-11671-1-git-send-email-marcus@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-14T06:45:24Z","receivedAt":"2008-08-14T06:45:24Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marcus Griep, Thu, Aug 14, 2008 06:21:24 +0200:\n>  SYNOPSIS\n>  --------\n> -'git count-objects' [-v]\n> +'git count-objects' [-v [-H]]\n>  \n\nGNU ls and du use \"-h\", with du using -H for SI units.\n"},{"id":"87163","messageId":"48A3E142.9060606@viscovery.net","threadId":"14990","inReplyTo":"1218687684-11671-1-git-send-email-marcus@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-08-14T07:39:46Z","receivedAt":"2008-08-14T07:39:46Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marcus Griep schrieb:\n> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n> +{\n> +\tchar human_readable_prefixes[10] = \"BKMGTPEZY\";\n> +\tif (buf_size < 5)\n> +\t\tdie(\"insufficient buffer size\");\n> +\tint i = 0;\n> +\tfor (; i < 8 && size >= 1000 ; ++i, size = size / 1024)\n> +\t\t;\n> +\tif (size >= 1000)\n> +\t\tdie(\"size greater than 999Y\");\n\nNo need to die here. Just make the buffer large enough, and you can have\nsomething that is as large as 18446744073709551615Y.\n\n-- Hannes\n"},{"id":"87193","messageId":"48A43B2A.7010702@griep.us","threadId":"14990","inReplyTo":"20080814064524.GA4379@blimp.local","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T14:03:22Z","receivedAt":"2008-08-14T14:03:22Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Alex Riesen wrote:\n> GNU ls and du use \"-h\", with du using -H for SI units.\n\ngit's parse options plays interference here and injects the usage\nand exits if it finds the '-h' option.  Is there a way to get around\nthat?\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87191","messageId":"alpine.DEB.1.00.0808141604190.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"14990","inReplyTo":"7vskt8f9x2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-14T14:05:28Z","receivedAt":"2008-08-14T14:05:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Aug 2008, Junio C Hamano wrote:\n\n> \"Shawn O. Pearce\" <spearce@spearce.org> writes:\n> \n> > Marcus Griep <marcus@griep.us> wrote:\n> >> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt\n> >> index 75a8da1..291bc5e 100644\n> >> --- a/Documentation/git-count-objects.txt\n> >> +++ b/Documentation/git-count-objects.txt\n> >> +++ b/builtin-count-objects.c\n> > ...\n> >> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n> >\n> > Hmm.  This probably should be static.  Or if it really is meant\n> > to be a utility for use elsewhere in Git, moved to someplace where\n> > string handling is done.  Its not strbuf related, but maybe strbuf.c\n> > is a better location for this sort of library function.\n> \n> Yes, with customizable precision (so that the caller can control \"1.6k\" vs\n> \"1.62k\"), and perhaps cutomizable unit (so that you can use this for\n> \"3.6kB\" and \"2.6Mbps\"), this kind of thing is a good candidate to be a\n> library function in strbuf.c.\n\nOr, should it ever be merged into git.git, the strbuf_vaddf() routine I \nwrote.\n\nCiao,\nDscho\n"},{"id":"87194","messageId":"48A43C8A.9010309@griep.us","threadId":"14990","inReplyTo":"48A3E142.9060606@viscovery.net","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T14:09:14Z","receivedAt":"2008-08-14T14:09:14Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Johannes Sixt wrote:\n> No need to die here. Just make the buffer large enough, and you can have\n> something that is as large as 18446744073709551615Y.\n\nIn my initial rendition, the output was guaranteed not to be longer than 5\ncharacters.  However, you're right that there's no need to die, but perhaps\njust return a negative value equal to the size over the user's requested\nmaxlen.\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87195","messageId":"48A4407F.6080902@griep.us","threadId":"14990","inReplyTo":"7vskt8f9x2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T14:26:07Z","receivedAt":"2008-08-14T14:26:07Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Junio C Hamano wrote:\n>     extern int human_readable(struct strbuf *,\n>     \t\t\t      double value, int precision,\n>                               const char **unit);\n> \n>     static const char **size_unit = {\n>     \t\"byte\", \"KB\", \"MB\", \"GB\", NULL,\n>     };\n>     static const char **throughput_unit = {\n>     \t\"bps\", \"Kbps\", \"Mbps\", \"Gbps\", NULL,\n>     };\n> \n>     human_readble(&sb, (double) bytes_transferred, 0, size_unit);\n>     human_readble(&sb, (double) throughput, 2, throughput_unit);\n\nHere's what I'm looking at as a new signature:\n\nextern int strbuf_add_human_readable(struct strbuf *,\n\t\t\t\tdouble value, int maxlen,\n\t\t\t\tint scale, const char *suffix,\n\t\t\t\tint flags);\n\nwhere 'maxlen' specifies the longest string that should be returned.\nThat will make it easier for any pretty-ish formatting like ls and\ndu use. A value of 0 is unlimited length.\n\n'scale' is used to specify a boundary, above which value should be\nreduced, and below which it should be reported. Commonly this is\n1000.  If 0, then it will find a scale that best fits into 'maxlen'.\nIf both 'maxlen' and 'scale' are 0, then it will use the default\nof 1000.\n\n'suffix' is appended onto every formatted string.  This would often be\n\"\", \"B\", \"bps\".\n\n'flags' would provide the ability to switch between a binary (1024)\nand an si (1000) period.  Also, adding a space between number and\nunit.\n\nOn success, would return 0.  If maxlen is specified and there is not\nenough space given the scale or an inordinately large value, return\n-n, where n is the amount of additional length that would have been\nneeded.\n\nDoes this sound appropriate?\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87197","messageId":"20080814151451.GA10544@machine.or.cz","threadId":"14990","inReplyTo":"1218687684-11671-1-git-send-email-marcus@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-14T15:14:51Z","receivedAt":"2008-08-14T15:14:51Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 14, 2008 at 12:21:24AM -0400, Marcus Griep wrote:\n> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */)\n> +{\n> +\tchar human_readable_prefixes[10] = \"BKMGTPEZY\";\n> +\tif (buf_size < 5)\n> +\t\tdie(\"insufficient buffer size\");\n> +\tint i = 0;\n> +\tfor (; i < 8 && size >= 1000 ; ++i, size = size / 1024)\n> +\t\t;\n> +\tif (size >= 1000)\n> +\t\tdie(\"size greater than 999Y\");\n> +\tsprintf(buf, \"%.*f%c\",\n> +\t\tsize < 10 ? 1 : 0,\n> +\t\tsize,\n> +\t\thuman_readable_prefixes[i]\n> +\t\t);\n> +}\n\nAre you aware of progress.c:throughput_string()? It would make sense to\nuse the same code in both instances.\n\nI'd prefer you to keep using binary units instead of the ambiguous\nprefixes, since we should keep our output consistent and I believe they\nusually end up to be the least confusing choice. (Otherwise, don't you\nwant to use \"bkM\" instead of \"BKM\"? I never really know.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"87200","messageId":"48A45CC9.5040708@griep.us","threadId":"14990","inReplyTo":"20080814151451.GA10544@machine.or.cz","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T16:26:49Z","receivedAt":"2008-08-14T16:26:49Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Are you aware of progress.c:throughput_string()? It would make sense to\n> use the same code in both instances.\n\nI was not. After reviewing it, it is limited to its purposes (who's got\ntransfer speeds in TiB/s?), but consolidating the human-readable-ness is\na good idea.\n\n> I'd prefer you to keep using binary units instead of the ambiguous\n> prefixes, since we should keep our output consistent and I believe they\n> usually end up to be the least confusing choice. (Otherwise, don't you\n> want to use \"bkM\" instead of \"BKM\"? I never really know.)\n\nIn general, \"b\" would be supplied as a part of the suffix, so that is no\nlonger in the prefix list.  The distinction comes with kilo vs. kibi.  In\nan earlier email reply, I mentioned a flag to denote SI versus binary\nperiods.  In common nomenclature, Kilo (1000) is designated 'k', while\nKibi (1024) is designated 'K' (the 'i' after the 'K' is supplied by the\nsuffix if desired).  Thus, if the user wants binary, they'll get the capital\n'K', and if they want SI, they'll get the lowercase 'k'.\n\nSound reasonable?\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87201","messageId":"20080814163446.GD10360@machine.or.cz","threadId":"14990","inReplyTo":"48A45CC9.5040708@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-14T16:34:46Z","receivedAt":"2008-08-14T16:34:46Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 14, 2008 at 12:26:49PM -0400, Marcus Griep wrote:\n> Petr Baudis wrote:\n> > Are you aware of progress.c:throughput_string()? It would make sense to\n> > use the same code in both instances.\n> \n> I was not. After reviewing it, it is limited to its purposes, but\n> consolidating the human-readable-ness is a good idea.\n\nOf course, it would need an usage overhaul. But otherwise, it seems\nfine? Terabyte-sized objects in Git would be very troublesome venture\nfor many reasons.\n\n> (who's got transfer speeds in TiB/s?)\n\nMaybe Dana Brown? ;-)\n\n> > I'd prefer you to keep using binary units instead of the ambiguous\n> > prefixes, since we should keep our output consistent and I believe they\n> > usually end up to be the least confusing choice. (Otherwise, don't you\n> > want to use \"bkM\" instead of \"BKM\"? I never really know.)\n> \n> In general, \"b\" would be supplied as a part of the suffix, so that is no\n> longer in the prefix list.  The distinction comes with kilo vs. kibi.  In\n> an earlier email reply, I mentioned a flag to denote SI versus binary\n> periods.  In common nomenclature, Kilo (1000) is designated 'k', while\n> Kibi (1024) is designated 'K' (the 'i' after the 'K' is supplied by the\n> suffix if desired).  Thus, if the user wants binary, they'll get the capital\n> 'K', and if they want SI, they'll get the lowercase 'k'.\n> \n> Sound reasonable?\n\nI'm confused - you didn't seem to really address my suggestion. Is there\na good reason _not_ to go with the /.iB/ prefixes, and just forget about\nSI? Who is ever going to need SI?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"87202","messageId":"48A46058.6090407@griep.us","threadId":"14990","inReplyTo":"20080814163446.GD10360@machine.or.cz","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Marcus Griep","fromEmail":"marcus@griep.us","sentAt":"2008-08-14T16:42:00Z","receivedAt":"2008-08-14T16:42:00Z","isPatch":true,"sender":{"key":"marcus@griep.us","avatar":"https://gravatar.com/avatar/0a841f2aad3f9a38c9bcf87a567c2a1751cb08924bae1bc46ee171395bcf9794?d=mp&s=160"},"body":"Petr Baudis wrote:\n> I'm confused - you didn't seem to really address my suggestion. Is there\n> a good reason _not_ to go with the /.iB/ prefixes, and just forget about\n> SI? Who is ever going to need SI?\n\nIt's more of a not limiting support, but in the spirit of YAGNI, I can\nforget about SI until we find some reason to actually want it, and then\nadd it at that point.\n\nAs for the /.iB/ prefixes, other than the actual magnitude prefix, 'iB',\n'B', 'bps', etc. would be supplied as a suffix by the consumer so as not\nto assume that we will be formatting bytes or widgets, since conceivably\nyou may want to know that there are 203k objects (which would be an SI\nuse) or are transferring at a rate of 1.6k blobs/s.\n\nIn which case, it might be preferable to leave the SI in, since it would\nallow more than just bytes to be formatted in shorter, human-readable\nform.\n\n-- \nMarcus Griep\nGPG Key ID: 0x5E968152\n——\nhttp://www.boohaunt.net\nאת.ψο´\n"},{"id":"87218","messageId":"20080814185131.GA14858@steel.home","threadId":"14990","inReplyTo":"48A43B2A.7010702@griep.us","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-14T18:51:31Z","receivedAt":"2008-08-14T18:51:31Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200:\n> Alex Riesen wrote:\n> > GNU ls and du use \"-h\", with du using -H for SI units.\n> \n> git's parse options plays interference here and injects the usage\n> and exits if it finds the '-h' option.  Is there a way to get around\n> that?\n\nAFAICS - no. I'd suggest removing \"-h\" from the unconditionally\nreserved list of options (untested patch attached). \"--help\" is well\nknown (which could be a reason why coreutils uses just it).\n\nOn somewhat similar note, how about be a bit _less_ user-friendly in\nthe text messages? IOW, make things like \"something didn't work,\nplease try doing 'git something-else'\" configurable (ok, active by\ndefault, by deactivatable). These take an awful lot of screen space.\nThe builtin fetch, checkout, add (the most often used commands) are\nthe chattiest. The text in commit buffer takes almost half of screen,\ntoo.\n\n--\n\ndiff --git a/parse-options.c b/parse-options.c\nindex fd08bb4..7f85cd7 100644\n--- a/parse-options.c\n+++ b/parse-options.c\n@@ -267,8 +267,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,\n \n \t\tif (arg[1] != '-') {\n \t\t\tctx->opt = arg + 1;\n-\t\t\tif (*ctx->opt == 'h')\n-\t\t\t\treturn parse_options_usage(usagestr, options);\n \t\t\tswitch (parse_short_opt(ctx, options)) {\n \t\t\tcase -1:\n \t\t\t\treturn parse_options_usage(usagestr, options);\n@@ -278,8 +276,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,\n \t\t\tif (ctx->opt)\n \t\t\t\tcheck_typos(arg + 1, options);\n \t\t\twhile (ctx->opt) {\n-\t\t\t\tif (*ctx->opt == 'h')\n-\t\t\t\t\treturn parse_options_usage(usagestr, options);\n \t\t\t\tswitch (parse_short_opt(ctx, options)) {\n \t\t\t\tcase -1:\n \t\t\t\t\treturn parse_options_usage(usagestr, options);\n"},{"id":"87300","messageId":"20080815092249.GA6024@artemis.madism.org","threadId":"14990","inReplyTo":"20080814185131.GA14858@steel.home","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-08-15T09:22:50Z","receivedAt":"2008-08-15T09:22:50Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Aug 14, 2008 at 06:51:31PM +0000, Alex Riesen wrote:\n> Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200:\n> > Alex Riesen wrote:\n> > > GNU ls and du use \"-h\", with du using -H for SI units.\n> > \n> > git's parse options plays interference here and injects the usage\n> > and exits if it finds the '-h' option.  Is there a way to get around\n> > that?\n> \n> AFAICS - no. I'd suggest removing \"-h\" from the unconditionally\n> reserved list of options (untested patch attached). \"--help\" is well\n> known (which could be a reason why coreutils uses just it).\n\n  But --help is not as terse as -h is, and it would be going backwards\nnot having it anymore.\n\n> On somewhat similar note, how about be a bit _less_ user-friendly in\n> the text messages? IOW, make things like \"something didn't work,\n> please try doing 'git something-else'\" configurable (ok, active by\n> default, by deactivatable). These take an awful lot of screen space.\n> The builtin fetch, checkout, add (the most often used commands) are\n> the chattiest. The text in commit buffer takes almost half of screen,\n> too.\n\n  We probably want to reorganize some of our options so that it's less\nverbose, but FWIW I prefer the git foo -h wrt git foo --help because I\nusually *know* there is an option, and git foo -h is way easier to grep\nwith the eye than the man page.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"87552","messageId":"20080818172822.GB6014@blimp.local","threadId":"14990","inReplyTo":"20080815092249.GA6024@artemis.madism.org","subject":"Re: [PATCH 2] count-objects: add human-readable size option","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-18T17:28:22Z","receivedAt":"2008-08-18T17:28:22Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Pierre Habouzit, Fri, Aug 15, 2008 11:22:50 +0200:\n> \n> But --help is not as terse as -h is, and it would be going backwards\n> not having it anymore.\n> \n\nBTW, ls-remote (which is not ported to the options handling code yet)\nalso has \"-h\" (short for \"--heads\").\n"}]}