From: Josh Steadmon <steadmon@google.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com
Subject: [PATCH v2 0/1] Expand abbreviated filters
Date: Mon, 7 Jan 2019 16:17:08 -0800 [thread overview]
Message-ID: <cover.1546906008.git.steadmon@google.com> (raw)
In-Reply-To: <cover.1545261186.git.steadmon@google.com>
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
--
2.20.1.97.g81188d93c3-goog
next prev parent reply other threads:[~2019-01-08 0:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 23:21 [RFC PATCH 0/1] Expand abbreviated filters Josh Steadmon
2018-12-19 23:21 ` [RFC PATCH 1/1] filter-options: Expand abbreviated numbers Josh Steadmon
2019-01-02 23:15 ` Junio C Hamano
2019-01-07 21:25 ` Josh Steadmon
2019-01-07 22:12 ` Junio C Hamano
2019-01-07 22:18 ` Junio C Hamano
2019-01-08 0:17 ` Josh Steadmon [this message]
2019-01-08 0:17 ` [PATCH v2 " Josh Steadmon
2019-01-09 12:23 ` SZEDER Gábor
2019-01-09 18:55 ` Josh Steadmon
2019-01-09 19:20 ` SZEDER Gábor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1546906008.git.steadmon@google.com \
--to=steadmon@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.