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

From: Jakub Narębski <jnareb@gmail.com>
Date: Jun 20, 2015, 15:31 UTC
Message-ID: <55858737.6070207@gmail.com>
In-Reply-To: <xmqqh9q38ruq.fsf@gitster.dls.corp.google.com>

W dniu 2015-06-19 o 20:39, Junio C Hamano pisze:

Show 15 quoted lines

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

On the output side it is often called --human-readable (e.g. du(1)), I don't know how it is called on input side (e.g. in 'dd' and friends).

Show 13 quoted lines

> 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?

OPT_HUMAN_READABLE_INTEGER() is probably out as too long? ;-P

-- 
Jakub Narębski