[PATCH v2 0/1] Expand abbreviated filters

NOTE: this patch is based on top of md/list-objects-filter-by-depth

Currently, git clients pass filter specs verbatim over the network and to subprocesses. We support various scaling suffixes for parameters on these limits (via git_parse_ulong()), but other implementations may not support the same suffixes. It would be better to only pass fully- expanded numbers in this case, and keep the expansion logic completely on the client side.

This patch updates the protocol-v2 doc to specify that clients SHOULD expand abbreviations in filter specifications before passing them to other processes. It adds a new function "expand_list_objects_filter_spec()" in list-objects-filter-options.c that implements the expansion logic, and updates users of the filter_spec field to instead expand the spec first.

Changes since V1:
  * Changed "MUST" to "SHOULD" in protocol-v2.txt
  * Noted specific suffixes that receivers SHOULD accept

Josh Steadmon (1):
  filter-options: Expand abbreviated numbers

 Documentation/technical/protocol-v2.txt |  8 +++++++-
 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, 94 insertions(+), 16 deletions(-)

Range-diff against v1:
1:  d324e78369 ! 1:  d35827de35 filter-options: Expand abbreviated numbers
    @@ -20,10 +20,13 @@
      	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.
    ++	`rev-list` for possible "filter-spec" values. When communicating
    ++	with other processes, senders SHOULD translate scaled integers
    ++	(e.g. "1k") into a fully-expanded form (e.g. "1024") to aid
    ++	interoperability with older receivers that may not understand
    ++	newly-invented scaling suffixes. However, receivers SHOULD
    ++	accept the following suffixes: 'k', 'm', and 'g' for 1024,
    ++	1048576, and 1073741824, respectively.
      
      If the 'ref-in-want' feature is advertised, the following argument can
      be included in the client's request as well as the potential addition of