Re: [RFC PATCH 1/1] filter-options: Expand abbreviated numbers
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 2, 2019, 23:15 UTC
- Message-ID
- <xmqqsgyaircj.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <d324e7836928940a4df0b43da3ffeb8526feac61.1545261186.git.steadmon@google.com>
Josh Steadmon <steadmon@google.com> writes:
Show 34 quoted lines
> When communicating with a remote server or a subprocess, use expanded > numbers rather than abbreviated numbers in the object filter spec (e.g. > "limit:blob=1k" becomes "limit:blob=1024"). > > Update the protocol docs to note that clients should always perform this > expansion, to allow for more compatibility between server > implementations. > > Signed-off-by: Josh Steadmon <steadmon@google.com> > --- > Documentation/technical/protocol-v2.txt | 5 ++++- > builtin/clone.c | 6 +++++- > builtin/fetch.c | 7 ++++++- > fetch-pack.c | 15 ++++++++++++--- > list-objects-filter-options.c | 20 ++++++++++++++++++-- > list-objects-filter-options.h | 17 +++++++++++++++-- > t/t6112-rev-list-filters-objects.sh | 17 +++++++++++++++++ > transport-helper.c | 13 +++++++++---- > upload-pack.c | 7 +++++-- > 9 files changed, 91 insertions(+), 16 deletions(-) > > diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt > index 09e4e0273f..d001372404 100644 > --- a/Documentation/technical/protocol-v2.txt > +++ b/Documentation/technical/protocol-v2.txt > @@ -296,7 +296,10 @@ included in the client's request: > Request that various objects from the packfile be omitted > using one of several filtering techniques. These are intended > for use with partial clone and partial fetch operations. See > - `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".