# [PATCH] count-objects: Add total pack size to verbose output 18 messages from 2008-08-13 to 2008-08-18. Participants: Marcus Griep, Shawn O. Pearce, Junio C Hamano, Alex Riesen, Johannes Sixt, Johannes Schindelin, Petr Baudis, Pierre Habouzit. Thread: https://gitlist.dev/t/14990 ## Marcus Griep, 2008-08-13 20:05 Subject: [PATCH] count-objects: Add total pack size to verbose output Message-ID: <1218657910-22096-1-git-send-email-marcus@griep.us> URL: https://gitlist.dev/e/1218657910-22096-1-git-send-email-marcus%40griep.us ``` Adds the total pack size (including indexes) the verbose count-objects output, floored to the nearest kilobyte. Signed-off-by: Marcus Griep --- I used the pack size including the size of the associated indexes in computing total pack size since it more closely represents the disk usage of each pack. If separate reporting is preferred, they can be split apart. builtin-count-objects.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/builtin-count-objects.c b/builtin-count-objects.c index 91b5487..249040b 100644 --- a/builtin-count-objects.c +++ b/builtin-count-objects.c @@ -104,6 +104,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix) if (verbose) { struct packed_git *p; unsigned long num_pack = 0; + unsigned long size_pack = 0; if (!packed_git) prepare_packed_git(); for (p = packed_git; p; p = p->next) { @@ -112,12 +113,14 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix) if (open_pack_index(p)) continue; packed += p->num_objects; + size_pack += p->pack_size + p->index_size; num_pack++; } printf("count: %lu\n", loose); printf("size: %lu\n", loose_size / 2); printf("in-pack: %lu\n", packed); printf("packs: %lu\n", num_pack); + printf("size-pack: %lu\n", size_pack / 1024); printf("prune-packable: %lu\n", packed_loose); printf("garbage: %lu\n", garbage); } -- 1.6.0.rc2.6.g8eda3 ``` ## Marcus Griep, 2008-08-14 04:21 Subject: [PATCH 2] count-objects: add human-readable size option Message-ID: <1218687684-11671-1-git-send-email-marcus@griep.us> URL: https://gitlist.dev/e/1218687684-11671-1-git-send-email-marcus%40griep.us In-Reply-To: <1218657910-22096-1-git-send-email-marcus@griep.us> ``` Adds a human readable size option to the verbose output of count-objects for loose and pack object size totals. Updates documentation to match. Signed-off-by: Marcus Griep --- I thought that this would be a nice addition to 'git count-objects'. This patch depends upon my earlier patch to count-objects, but this patch should be easily separable from its dependency should that one not be accepted. Documentation/git-count-objects.txt | 13 +++++++--- builtin-count-objects.c | 41 +++++++++++++++++++++++++++++++--- 2 files changed, 46 insertions(+), 8 deletions(-) diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index 75a8da1..291bc5e 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption SYNOPSIS -------- -'git count-objects' [-v] +'git count-objects' [-v [-H]] DESCRIPTION ----------- @@ -21,9 +21,14 @@ OPTIONS --verbose:: In addition to the number of loose objects and disk space consumed, it reports the number of in-pack - objects, number of packs, and number of objects that can be - removed by running `git prune-packed`. - + objects, number of packs, disk space consumed by those packs + and number of objects that can be removed by running + `git prune-packed`. + +-H:: +--human-sizes:: + Displays sizes reported by `--verbose` in a more + human-readable format. (e.g. 22M or 1.5G) Author ------ diff --git a/builtin-count-objects.c b/builtin-count-objects.c index 249040b..1eb73be 100644 --- a/builtin-count-objects.c +++ b/builtin-count-objects.c @@ -67,13 +67,30 @@ static void count_objects(DIR *d, char *path, int len, int verbose, } static char const * const count_objects_usage[] = { - "git count-objects [-v]", + "git count-objects [-v [-H]]", NULL }; +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) +{ + char human_readable_prefixes[10] = "BKMGTPEZY"; + if (buf_size < 5) + die("insufficient buffer size"); + int i = 0; + for (; i < 8 && size >= 1000 ; ++i, size = size / 1024) + ; + if (size >= 1000) + die("size greater than 999Y"); + sprintf(buf, "%.*f%c", + size < 10 ? 1 : 0, + size, + human_readable_prefixes[i] + ); +} + int cmd_count_objects(int argc, const char **argv, const char *prefix) { - int i, verbose = 0; + int i, verbose = 0, human_readable = 0; const char *objdir = get_object_directory(); int len = strlen(objdir); char *path = xmalloc(len + 50); @@ -81,6 +98,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix) unsigned long loose_size = 0; struct option opts[] = { OPT__VERBOSE(&verbose), + OPT_BOOLEAN('H', "--human-sizes", &human_readable, + "displays sizes in human readable format"), OPT_END(), }; @@ -117,10 +136,24 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix) num_pack++; } printf("count: %lu\n", loose); - printf("size: %lu\n", loose_size / 2); + printf("size: "); + if (human_readable) { + char buf[sizeof("999Y")]; + human_readable_size(buf, sizeof(buf), loose_size * 512); + printf("%s\n", buf); + } + else + printf("%lu\n", loose_size / 2); printf("in-pack: %lu\n", packed); printf("packs: %lu\n", num_pack); - printf("size-pack: %lu\n", size_pack / 1024); + printf("size-pack: "); + if (human_readable) { + char buf[sizeof("999Y")]; + human_readable_size(buf, sizeof(buf), size_pack); + printf("%s\n", buf); + } + else + printf("%lu\n", size_pack / 1024); printf("prune-packable: %lu\n", packed_loose); printf("garbage: %lu\n", garbage); } -- 1.6.0.rc2.6.g8eda3 ``` ## Shawn O. Pearce, 2008-08-14 04:38 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080814043817.GC11232@spearce.org> URL: https://gitlist.dev/e/20080814043817.GC11232%40spearce.org In-Reply-To: <1218687684-11671-1-git-send-email-marcus@griep.us> ``` Marcus Griep wrote: > diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt > index 75a8da1..291bc5e 100644 > --- a/Documentation/git-count-objects.txt > +++ b/Documentation/git-count-objects.txt > +++ b/builtin-count-objects.c ... > +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) Hmm. This probably should be static. Or if it really is meant to be a utility for use elsewhere in Git, moved to someplace where string handling is done. Its not strbuf related, but maybe strbuf.c is a better location for this sort of library function. If you do move this to strbuf.c, how about having it take a strbuf in and appending the formatted text onto it? You'll neer have to worry about the buffer being too small and it fits into the whole strbuf.c module thing. If you keep this static here in builtin-count-objects.c, how about making the char *buf static scoped to the function, so you don't need to pass the buffer, its size, nor check its size? > +{ > + char human_readable_prefixes[10] = "BKMGTPEZY"; > + if (buf_size < 5) > + die("insufficient buffer size"); > + int i = 0; We don't declare variables after statements. Please declare all variables at the start of the block as not all compilers we support support this C99 syntax. Oh, and welcome to Git. I saw your SVN patches. Glad to see you hacking. ;-) > + for (; i < 8 && size >= 1000 ; ++i, size = size / 1024) > + ; > + if (size >= 1000) > + die("size greater than 999Y"); > + sprintf(buf, "%.*f%c", > + size < 10 ? 1 : 0, > + size, > + human_readable_prefixes[i] > + ); > +} > + -- Shawn. ``` ## Marcus Griep, 2008-08-14 04:44 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A3B81B.10804@griep.us> URL: https://gitlist.dev/e/48A3B81B.10804%40griep.us In-Reply-To: <20080814043817.GC11232@spearce.org> ``` Shawn O. Pearce wrote: > Hmm. This probably should be static. Or if it really is meant > to be a utility for use elsewhere in Git, moved to someplace where > string handling is done. Its not strbuf related, but maybe strbuf.c > is a better location for this sort of library function. > > If you do move this to strbuf.c, how about having it take a strbuf > in and appending the formatted text onto it? You'll neer have to > worry about the buffer being too small and it fits into the whole > strbuf.c module thing. > > If you keep this static here in builtin-count-objects.c, how about > making the char *buf static scoped to the function, so you don't > need to pass the buffer, its size, nor check its size? I'll take this into account. Though I didn't plan it to be a cross-git utility function, it probably could be, so I'll look at putting it in strbuf.c. > We don't declare variables after statements. Please declare all > variables at the start of the block as not all compilers we support > support this C99 syntax. This is the first time I've hacked on vanilla-C in about 5 years, so I'm quite rusty. Much less my first time hacking on perl, ever, in the case of git-svn. Thanks for the pointers. > Oh, and welcome to Git. I saw your SVN patches. Glad to see > you hacking. ;-) Glad to be a part. -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Junio C Hamano, 2008-08-14 05:22 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <7vskt8f9x2.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vskt8f9x2.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080814043817.GC11232@spearce.org> ``` "Shawn O. Pearce" writes: > Marcus Griep wrote: >> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt >> index 75a8da1..291bc5e 100644 >> --- a/Documentation/git-count-objects.txt >> +++ b/Documentation/git-count-objects.txt >> +++ b/builtin-count-objects.c > ... >> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) > > Hmm. This probably should be static. Or if it really is meant > to be a utility for use elsewhere in Git, moved to someplace where > string handling is done. Its not strbuf related, but maybe strbuf.c > is a better location for this sort of library function. Yes, with customizable precision (so that the caller can control "1.6k" vs "1.62k"), and perhaps cutomizable unit (so that you can use this for "3.6kB" and "2.6Mbps"), this kind of thing is a good candidate to be a library function in strbuf.c. >> +{ >> + char human_readable_prefixes[10] = "BKMGTPEZY"; This enumerates suffix if I am not mistaken. Do you have to say "10" here, or does the compiler counts them for you? >> + for (; i < 8 && size >= 1000 ; ++i, size = size / 1024) >> + ; I do not think you would need to use the magic number "8" here. I have this suspicion that the caller, if this is made into a generic library, would want to pass in a list of units, not magnitude suffixes, like this: extern int human_readable(struct strbuf *, double value, int precision, const char **unit); static const char **size_unit = { "byte", "KB", "MB", "GB", NULL, }; static const char **throughput_unit = { "bps", "Kbps", "Mbps", "Gbps", NULL, }; human_readble(&sb, (double) bytes_transferred, 0, size_unit); human_readble(&sb, (double) throughput, 2, throughput_unit); ``` ## Alex Riesen, 2008-08-14 06:45 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080814064524.GA4379@blimp.local> URL: https://gitlist.dev/e/20080814064524.GA4379%40blimp.local In-Reply-To: <1218687684-11671-1-git-send-email-marcus@griep.us> ``` Marcus Griep, Thu, Aug 14, 2008 06:21:24 +0200: > SYNOPSIS > -------- > -'git count-objects' [-v] > +'git count-objects' [-v [-H]] > GNU ls and du use "-h", with du using -H for SI units. ``` ## Johannes Sixt, 2008-08-14 07:39 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A3E142.9060606@viscovery.net> URL: https://gitlist.dev/e/48A3E142.9060606%40viscovery.net In-Reply-To: <1218687684-11671-1-git-send-email-marcus@griep.us> ``` Marcus Griep schrieb: > +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) > +{ > + char human_readable_prefixes[10] = "BKMGTPEZY"; > + if (buf_size < 5) > + die("insufficient buffer size"); > + int i = 0; > + for (; i < 8 && size >= 1000 ; ++i, size = size / 1024) > + ; > + if (size >= 1000) > + die("size greater than 999Y"); No need to die here. Just make the buffer large enough, and you can have something that is as large as 18446744073709551615Y. -- Hannes ``` ## Marcus Griep, 2008-08-14 14:03 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A43B2A.7010702@griep.us> URL: https://gitlist.dev/e/48A43B2A.7010702%40griep.us In-Reply-To: <20080814064524.GA4379@blimp.local> ``` Alex Riesen wrote: > GNU ls and du use "-h", with du using -H for SI units. git's parse options plays interference here and injects the usage and exits if it finds the '-h' option. Is there a way to get around that? -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Johannes Schindelin, 2008-08-14 14:05 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0808141604190.24820%40pacific.mpi-cbg.de.mpi-cbg.de In-Reply-To: <7vskt8f9x2.fsf@gitster.siamese.dyndns.org> ``` Hi, On Wed, 13 Aug 2008, Junio C Hamano wrote: > "Shawn O. Pearce" writes: > > > Marcus Griep wrote: > >> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt > >> index 75a8da1..291bc5e 100644 > >> --- a/Documentation/git-count-objects.txt > >> +++ b/Documentation/git-count-objects.txt > >> +++ b/builtin-count-objects.c > > ... > >> +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) > > > > Hmm. This probably should be static. Or if it really is meant > > to be a utility for use elsewhere in Git, moved to someplace where > > string handling is done. Its not strbuf related, but maybe strbuf.c > > is a better location for this sort of library function. > > Yes, with customizable precision (so that the caller can control "1.6k" vs > "1.62k"), and perhaps cutomizable unit (so that you can use this for > "3.6kB" and "2.6Mbps"), this kind of thing is a good candidate to be a > library function in strbuf.c. Or, should it ever be merged into git.git, the strbuf_vaddf() routine I wrote. Ciao, Dscho ``` ## Marcus Griep, 2008-08-14 14:09 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A43C8A.9010309@griep.us> URL: https://gitlist.dev/e/48A43C8A.9010309%40griep.us In-Reply-To: <48A3E142.9060606@viscovery.net> ``` Johannes Sixt wrote: > No need to die here. Just make the buffer large enough, and you can have > something that is as large as 18446744073709551615Y. In my initial rendition, the output was guaranteed not to be longer than 5 characters. However, you're right that there's no need to die, but perhaps just return a negative value equal to the size over the user's requested maxlen. -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Marcus Griep, 2008-08-14 14:26 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A4407F.6080902@griep.us> URL: https://gitlist.dev/e/48A4407F.6080902%40griep.us In-Reply-To: <7vskt8f9x2.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > extern int human_readable(struct strbuf *, > double value, int precision, > const char **unit); > > static const char **size_unit = { > "byte", "KB", "MB", "GB", NULL, > }; > static const char **throughput_unit = { > "bps", "Kbps", "Mbps", "Gbps", NULL, > }; > > human_readble(&sb, (double) bytes_transferred, 0, size_unit); > human_readble(&sb, (double) throughput, 2, throughput_unit); Here's what I'm looking at as a new signature: extern int strbuf_add_human_readable(struct strbuf *, double value, int maxlen, int scale, const char *suffix, int flags); where 'maxlen' specifies the longest string that should be returned. That will make it easier for any pretty-ish formatting like ls and du use. A value of 0 is unlimited length. 'scale' is used to specify a boundary, above which value should be reduced, and below which it should be reported. Commonly this is 1000. If 0, then it will find a scale that best fits into 'maxlen'. If both 'maxlen' and 'scale' are 0, then it will use the default of 1000. 'suffix' is appended onto every formatted string. This would often be "", "B", "bps". 'flags' would provide the ability to switch between a binary (1024) and an si (1000) period. Also, adding a space between number and unit. On success, would return 0. If maxlen is specified and there is not enough space given the scale or an inordinately large value, return -n, where n is the amount of additional length that would have been needed. Does this sound appropriate? -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Petr Baudis, 2008-08-14 15:14 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080814151451.GA10544@machine.or.cz> URL: https://gitlist.dev/e/20080814151451.GA10544%40machine.or.cz In-Reply-To: <1218687684-11671-1-git-send-email-marcus@griep.us> ``` On Thu, Aug 14, 2008 at 12:21:24AM -0400, Marcus Griep wrote: > +void human_readable_size(char *buf, int buf_size, double size /* in bytes */) > +{ > + char human_readable_prefixes[10] = "BKMGTPEZY"; > + if (buf_size < 5) > + die("insufficient buffer size"); > + int i = 0; > + for (; i < 8 && size >= 1000 ; ++i, size = size / 1024) > + ; > + if (size >= 1000) > + die("size greater than 999Y"); > + sprintf(buf, "%.*f%c", > + size < 10 ? 1 : 0, > + size, > + human_readable_prefixes[i] > + ); > +} Are you aware of progress.c:throughput_string()? It would make sense to use the same code in both instances. 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.) -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ``` ## Marcus Griep, 2008-08-14 16:26 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A45CC9.5040708@griep.us> URL: https://gitlist.dev/e/48A45CC9.5040708%40griep.us In-Reply-To: <20080814151451.GA10544@machine.or.cz> ``` 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 (who's got transfer speeds in TiB/s?), but consolidating the human-readable-ness is a good idea. > 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? -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Petr Baudis, 2008-08-14 16:34 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080814163446.GD10360@machine.or.cz> URL: https://gitlist.dev/e/20080814163446.GD10360%40machine.or.cz 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 ``` ## Marcus Griep, 2008-08-14 16:42 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <48A46058.6090407@griep.us> URL: https://gitlist.dev/e/48A46058.6090407%40griep.us In-Reply-To: <20080814163446.GD10360@machine.or.cz> ``` Petr Baudis wrote: > 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? It's more of a not limiting support, but in the spirit of YAGNI, I can forget about SI until we find some reason to actually want it, and then add it at that point. As for the /.iB/ prefixes, other than the actual magnitude prefix, 'iB', 'B', 'bps', etc. would be supplied as a suffix by the consumer so as not to assume that we will be formatting bytes or widgets, since conceivably you may want to know that there are 203k objects (which would be an SI use) or are transferring at a rate of 1.6k blobs/s. In which case, it might be preferable to leave the SI in, since it would allow more than just bytes to be formatted in shorter, human-readable form. -- Marcus Griep GPG Key ID: 0x5E968152 —— http://www.boohaunt.net את.ψο´ ``` ## Alex Riesen, 2008-08-14 18:51 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080814185131.GA14858@steel.home> URL: https://gitlist.dev/e/20080814185131.GA14858%40steel.home In-Reply-To: <48A43B2A.7010702@griep.us> ``` Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200: > Alex Riesen wrote: > > GNU ls and du use "-h", with du using -H for SI units. > > git's parse options plays interference here and injects the usage > and exits if it finds the '-h' option. Is there a way to get around > that? AFAICS - no. I'd suggest removing "-h" from the unconditionally reserved list of options (untested patch attached). "--help" is well known (which could be a reason why coreutils uses just it). On somewhat similar note, how about be a bit _less_ user-friendly in the text messages? IOW, make things like "something didn't work, please try doing 'git something-else'" configurable (ok, active by default, by deactivatable). These take an awful lot of screen space. The builtin fetch, checkout, add (the most often used commands) are the chattiest. The text in commit buffer takes almost half of screen, too. -- diff --git a/parse-options.c b/parse-options.c index fd08bb4..7f85cd7 100644 --- a/parse-options.c +++ b/parse-options.c @@ -267,8 +267,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx, if (arg[1] != '-') { ctx->opt = arg + 1; - if (*ctx->opt == 'h') - return parse_options_usage(usagestr, options); switch (parse_short_opt(ctx, options)) { case -1: return parse_options_usage(usagestr, options); @@ -278,8 +276,6 @@ int parse_options_step(struct parse_opt_ctx_t *ctx, if (ctx->opt) check_typos(arg + 1, options); while (ctx->opt) { - if (*ctx->opt == 'h') - return parse_options_usage(usagestr, options); switch (parse_short_opt(ctx, options)) { case -1: return parse_options_usage(usagestr, options); ``` ## Pierre Habouzit, 2008-08-15 09:22 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080815092249.GA6024@artemis.madism.org> URL: https://gitlist.dev/e/20080815092249.GA6024%40artemis.madism.org In-Reply-To: <20080814185131.GA14858@steel.home> ``` On Thu, Aug 14, 2008 at 06:51:31PM +0000, Alex Riesen wrote: > Marcus Griep, Thu, Aug 14, 2008 16:03:22 +0200: > > Alex Riesen wrote: > > > GNU ls and du use "-h", with du using -H for SI units. > > > > git's parse options plays interference here and injects the usage > > and exits if it finds the '-h' option. Is there a way to get around > > that? > > AFAICS - no. I'd suggest removing "-h" from the unconditionally > reserved list of options (untested patch attached). "--help" is well > known (which could be a reason why coreutils uses just it). But --help is not as terse as -h is, and it would be going backwards not having it anymore. > On somewhat similar note, how about be a bit _less_ user-friendly in > the text messages? IOW, make things like "something didn't work, > please try doing 'git something-else'" configurable (ok, active by > default, by deactivatable). These take an awful lot of screen space. > The builtin fetch, checkout, add (the most often used commands) are > the chattiest. The text in commit buffer takes almost half of screen, > too. We probably want to reorganize some of our options so that it's less verbose, but FWIW I prefer the git foo -h wrt git foo --help because I usually *know* there is an option, and git foo -h is way easier to grep with the eye than the man page. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Alex Riesen, 2008-08-18 17:28 Subject: Re: [PATCH 2] count-objects: add human-readable size option Message-ID: <20080818172822.GB6014@blimp.local> URL: https://gitlist.dev/e/20080818172822.GB6014%40blimp.local In-Reply-To: <20080815092249.GA6024@artemis.madism.org> ``` Pierre Habouzit, Fri, Aug 15, 2008 11:22:50 +0200: > > But --help is not as terse as -h is, and it would be going backwards > not having it anymore. > BTW, ls-remote (which is not ported to the options handling code yet) also has "-h" (short for "--heads"). ```