[PATCH] count-objects: Add total pack size to verbose output

[PATCH] count-objects: Add total pack size to verbose output

[Marcus Griep]

Adds the total pack size (including indexes) the verbose count-objects
output, floored to the nearest kilobyte.

Signed-off-by: Marcus Griep <marcus@griep.us>
---

 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

[PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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 <marcus@griep.us>
---

 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

Re: [PATCH 2] count-objects: add human-readable size option

[Shawn O. Pearce]

Marcus Griep <marcus@griep.us> 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.

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Marcus Griep <marcus@griep.us> 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);

Re: [PATCH 2] count-objects: add human-readable size option

[Alex Riesen]

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.

Re: [PATCH 2] count-objects: add human-readable size option

[Johannes Sixt]

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

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Johannes Schindelin]

Hi,

On Wed, 13 Aug 2008, Junio C Hamano wrote:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Marcus Griep <marcus@griep.us> 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

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Petr Baudis]

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

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Petr Baudis]

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

Re: [PATCH 2] count-objects: add human-readable size option

[Marcus Griep]

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
את.ψο´

Re: [PATCH 2] count-objects: add human-readable size option

[Alex Riesen]

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);

Re: [PATCH 2] count-objects: add human-readable size option

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH 2] count-objects: add human-readable size option

[Alex Riesen]

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").