Re: [RFC PATCH 1/1] filter-options: Expand abbreviated numbers

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2019, 22:12 UTC
Message-ID: <xmqqva306rsy.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190107212517.GA54613@google.com>

Josh Steadmon <steadmon@google.com> writes:

Show 14 quoted lines

>> > -	`rev-list` for possible "filter-spec" values.
>> > +	`rev-list` for possible "filter-spec" values. Clients MUST
>> > +	translate abbreviated numbers (e.g. "1k") into fully-expanded
>> > +	numbers (e.g. "1024") on the client side, so that the server
>> > +	does not need to implement unit parsing.
>> 
>> I suspect that it is too late now to retroactively say "MUST" here.
>> The best we may be able to do is to say "The sender SHOULD send a
>> plain integer without unit and the receiver SHOULD be prepared to
>> scale an integer with unit".
>> 
>
> In that case, do you think we should also specify that units should be
> interpreted as powers-of-2 rather than powers-of-10?

If we do not document the number scaling elsewhere, then we certainly should, but I somehow doubt it.

Documentation/git-config.txt does list these explicitly where it talks about --type=int, but these human-readable scaled integers are also used in command line arguments as well, so we may want to find a central place that is clear to the readers that the description applies to all of them and move the description there.