Re: [PATCH 2/3] Move unsigned long option parsing out of pack-objects.c

From: Junio C Hamano <gitster@pobox.com>
To: Charles Bailey <charles@hashpling.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] Move unsigned long option parsing out of pack-objects.c
Date: Fri, 19 Jun 2015 11:39:57 -0700	[thread overview]
Message-ID: <xmqqh9q38ruq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqq7fqza8bo.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Fri, 19 Jun 2015 10:58:51 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Except for the minor nits above, I think this is a good change.

Oh, I forgot to mention one thing.  I am not sure if this should be
called ULONG.  "unsigned long"-ness is not the most important part
of this thing from the end-user's point of view, and also from the
point of view of the programmer who supports end-users by using this
new feature.

It is "unlike OPT_INTEGER, the user can specify it as a human
readble scaled quantity" that is the reason to use this new thing.
I think we discussed to introduce OPT_HUMINT (HUM stands for HUMAN,
obviously) or some name like that a few years ago to do exactly
this, but that is not a great name, either.

I was tempted to suggest a name that has "size" in it, but because
places that we may conceivably want to use it in the future would be
to specify:

 - sizes, e.g. "split the packfiles into 4.3G chunks".

 - counts, e.g. "show me the most recent 2k commits".

 - bandwidth, e.g. "limit the transfer to consume at most 2M bps".

which is not limited to size, it is not a very good idea, either.

OPT_SCALED_ULONG(), or something with "scaled" in its name, perhaps?