From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Christian Couder <christian.couder@gmail.com>,
git@vger.kernel.org, John Cai <johncai86@gmail.com>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH 3/4] Add 'promisor-remote' capability to protocol v2
Date: Mon, 19 Aug 2024 13:00:11 -0700 [thread overview]
Message-ID: <xmqq5xrwe110.fsf@gitster.g> (raw)
In-Reply-To: <ZrDYIFolRlERFdUT@tanuki> (Patrick Steinhardt's message of "Mon, 5 Aug 2024 15:48:16 +0200")
Patrick Steinhardt <ps@pks.im> writes:
>> +In this case, or if the client doesn't want to use any promisor remote
>> +the server advertised, the client should reply only "promisor-remote"
>> +without any value or "=" sign after it.
>
> Why does the client have to advertise anything if they don't want to use
> any of the promisor remotes?
Yeah, it is not very well justified why an empty capability needs to
be sent (from both sides). My recommendation is to drop that part
of the design, but if there is a reason to keep, it should be done
by explaining how differently the other side should behave when the
capability is not sent at all and when the capability with no
promisor remote is sent.
>> +The "promisor.advertise" and "promisor.acceptFromServer" configuration
>> +options can be used on the server and client side respectively to
>> +control what they advertise or accept respectively. See the
>> +documentation of these configuration options for more information.
>
> One thing I'm not totally clear on is the consequence of this
> capability. What is the expected consequence if the client accepts one
> of the promisor remotes? What is the consequence if the client accepts
> none?
Yes, I also found the documentation lacking in that respect. The
series talks about how the exchange can proceed, without saying much
(if anything) about what both sides want to exchange promisor-remote
for---what effect does it have on the behaviour of both sides to
send one. I covered this point in one of my reviews a bit more.
https://lore.kernel.org/git/xmqqikwl2zca.fsf@gitster.g/
> In the former case I'd expect that the server is free to omit objects,
> but that isn't made explicit anywhere, I think. Also, is there any
> mechanism that tells the client exactly which objects have been omitted?
> In the latter case I assume that the result will be a full clone, that
> is the server fetched any objects it didn't have from the promisor?
>
> Or does the server side continue to only honor whatever the client has
> provided as object filters, but signals to the client that it shall
> please contact somebody else when backfilling those promised objects?
Thanks.
next prev parent reply other threads:[~2024-08-19 20:00 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 13:40 [PATCH 0/4] Introduce a "promisor-remote" capability Christian Couder
2024-07-31 13:40 ` [PATCH 1/4] version: refactor strbuf_sanitize() Christian Couder
2024-07-31 17:18 ` Junio C Hamano
2024-08-20 11:29 ` Christian Couder
2024-07-31 13:40 ` [PATCH 2/4] strbuf: refactor strbuf_trim_trailing_ch() Christian Couder
2024-07-31 17:29 ` Junio C Hamano
2024-07-31 21:49 ` Taylor Blau
2024-08-20 11:29 ` Christian Couder
2024-08-20 11:29 ` Christian Couder
2024-07-31 13:40 ` [PATCH 3/4] Add 'promisor-remote' capability to protocol v2 Christian Couder
2024-07-31 15:40 ` Taylor Blau
2024-08-20 11:32 ` Christian Couder
2024-08-20 17:01 ` Junio C Hamano
2024-09-10 16:32 ` Christian Couder
2024-07-31 16:16 ` Taylor Blau
2024-08-20 11:32 ` Christian Couder
2024-08-20 16:55 ` Junio C Hamano
2024-09-10 16:32 ` Christian Couder
2024-09-10 17:46 ` Junio C Hamano
2024-07-31 18:25 ` Junio C Hamano
2024-07-31 19:34 ` Junio C Hamano
2024-08-20 12:21 ` Christian Couder
2024-08-05 13:48 ` Patrick Steinhardt
2024-08-19 20:00 ` Junio C Hamano [this message]
2024-09-10 16:31 ` Christian Couder
2024-07-31 13:40 ` [PATCH 4/4] promisor-remote: check advertised name or URL Christian Couder
2024-07-31 18:35 ` Junio C Hamano
2024-09-10 16:32 ` Christian Couder
2024-07-31 16:01 ` [PATCH 0/4] Introduce a "promisor-remote" capability Junio C Hamano
2024-07-31 16:17 ` Taylor Blau
2024-09-10 16:29 ` [PATCH v2 " Christian Couder
2024-09-10 16:29 ` [PATCH v2 1/4] version: refactor strbuf_sanitize() Christian Couder
2024-09-10 16:29 ` [PATCH v2 2/4] strbuf: refactor strbuf_trim_trailing_ch() Christian Couder
2024-09-10 16:29 ` [PATCH v2 3/4] Add 'promisor-remote' capability to protocol v2 Christian Couder
2024-09-30 7:56 ` Patrick Steinhardt
2024-09-30 13:28 ` Christian Couder
2024-10-01 10:14 ` Patrick Steinhardt
2024-10-01 18:47 ` Junio C Hamano
2024-11-06 14:04 ` Patrick Steinhardt
2024-11-28 5:47 ` Junio C Hamano
2024-11-28 15:31 ` Christian Couder
2024-11-29 1:31 ` Junio C Hamano
2024-09-10 16:30 ` [PATCH v2 4/4] promisor-remote: check advertised name or URL Christian Couder
2024-09-30 7:57 ` Patrick Steinhardt
2024-09-26 18:09 ` [PATCH v2 0/4] Introduce a "promisor-remote" capability Junio C Hamano
2024-09-27 9:15 ` Christian Couder
2024-09-27 22:48 ` Junio C Hamano
2024-09-27 23:31 ` rsbecker
2024-09-28 10:56 ` Kristoffer Haugsbakk
2024-09-30 7:57 ` Patrick Steinhardt
2024-09-30 9:17 ` Christian Couder
2024-09-30 16:52 ` Junio C Hamano
2024-10-01 10:14 ` Patrick Steinhardt
2024-09-30 16:34 ` Junio C Hamano
2024-09-30 21:26 ` brian m. carlson
2024-09-30 22:27 ` Junio C Hamano
2024-10-01 10:13 ` Patrick Steinhardt
2024-12-06 12:42 ` [PATCH v3 0/5] " Christian Couder
2024-12-06 12:42 ` [PATCH v3 1/5] version: refactor strbuf_sanitize() Christian Couder
2024-12-07 6:21 ` Junio C Hamano
2025-01-27 15:07 ` Christian Couder
2024-12-06 12:42 ` [PATCH v3 2/5] strbuf: refactor strbuf_trim_trailing_ch() Christian Couder
2024-12-07 6:35 ` Junio C Hamano
2025-01-27 15:07 ` Christian Couder
2024-12-16 11:47 ` karthik nayak
2024-12-06 12:42 ` [PATCH v3 3/5] Add 'promisor-remote' capability to protocol v2 Christian Couder
2024-12-07 7:59 ` Junio C Hamano
2025-01-27 15:08 ` Christian Couder
2024-12-06 12:42 ` [PATCH v3 4/5] promisor-remote: check advertised name or URL Christian Couder
2024-12-06 12:42 ` [PATCH v3 5/5] doc: add technical design doc for large object promisors Christian Couder
2024-12-10 1:28 ` Junio C Hamano
2025-01-27 15:12 ` Christian Couder
2024-12-10 11:43 ` Junio C Hamano
2024-12-16 9:00 ` Patrick Steinhardt
2025-01-27 15:11 ` Christian Couder
2025-01-27 18:02 ` Junio C Hamano
2025-02-18 11:42 ` Christian Couder
2024-12-09 8:04 ` [PATCH v3 0/5] Introduce a "promisor-remote" capability Junio C Hamano
2024-12-09 10:40 ` Christian Couder
2024-12-09 10:42 ` Christian Couder
2024-12-09 23:01 ` Junio C Hamano
2025-01-27 15:05 ` Christian Couder
2025-01-27 19:38 ` Junio C Hamano
2025-01-27 15:16 ` [PATCH v4 0/6] " Christian Couder
2025-01-27 15:16 ` [PATCH v4 1/6] version: replace manual ASCII checks with isprint() for clarity Christian Couder
2025-01-27 15:16 ` [PATCH v4 2/6] version: refactor redact_non_printables() Christian Couder
2025-01-27 15:16 ` [PATCH v4 3/6] version: make redact_non_printables() non-static Christian Couder
2025-01-30 10:51 ` Patrick Steinhardt
2025-02-18 11:42 ` Christian Couder
2025-01-27 15:16 ` [PATCH v4 4/6] Add 'promisor-remote' capability to protocol v2 Christian Couder
2025-01-30 10:51 ` Patrick Steinhardt
2025-02-18 11:41 ` Christian Couder
2025-01-27 15:17 ` [PATCH v4 5/6] promisor-remote: check advertised name or URL Christian Couder
2025-01-27 23:48 ` Junio C Hamano
2025-01-28 0:01 ` Junio C Hamano
2025-01-30 10:51 ` Patrick Steinhardt
2025-02-18 11:41 ` Christian Couder
2025-02-18 11:42 ` Christian Couder
2025-01-27 15:17 ` [PATCH v4 6/6] doc: add technical design doc for large object promisors Christian Couder
2025-01-27 21:14 ` [PATCH v4 0/6] Introduce a "promisor-remote" capability Junio C Hamano
2025-02-18 11:40 ` Christian Couder
2025-02-18 11:32 ` [PATCH v5 0/3] " Christian Couder
2025-02-18 11:32 ` [PATCH v5 1/3] Add 'promisor-remote' capability to protocol v2 Christian Couder
2025-02-18 11:32 ` [PATCH v5 2/3] promisor-remote: check advertised name or URL Christian Couder
2025-02-18 11:32 ` [PATCH v5 3/3] doc: add technical design doc for large object promisors Christian Couder
2025-02-21 8:33 ` Patrick Steinhardt
2025-03-03 16:58 ` Junio C Hamano
2025-02-18 19:07 ` [PATCH v5 0/3] Introduce a "promisor-remote" capability Junio C Hamano
2025-02-21 8:34 ` Patrick Steinhardt
2025-02-21 18:40 ` Junio C Hamano
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=xmqq5xrwe110.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.com \
--cc=ps@pks.im \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).