Josh Steadmon <steadmon@xxxxxxxxxx> writes: > 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@xxxxxxxxxx> > --- > 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".
