[0/4] Introduce a "promisor-remote" capability

Message

Christian Couder July 31, 2024, 1:40 p.m. UTC

Earlier this year, I sent 3 versions of a patch series with the goal
of allowing a client C to clone from a server S while using the same
promisor remote X that S already use. See:

https://lore.kernel.org/git/[e-mail]/

Junio suggested to instead implement that feature using:

"a protocol extension that lets S tell C that S wants C to fetch
missing objects from X (which means that if C knows about X in its
".git/config" then there is no need for end-user interaction at all),
or a protocol extension that C tells S that C is willing to see
objects available from X omitted when S does not have them (again,
this could be done by looking at ".git/config" at C, but there may be
security implications???)"

This patch series implements that protocol extension called
"promisor-remote" (that name is open to change or simplification)
which allows S and C to agree on C using X directly or not.

I have tried to implement it in a quite generic way that could allow S
and C to share more information about promisor remotes and how to use
them.

For now C doesn't use the information it gets from S when cloning.
That information is only used to decide if C is Ok to use the promisor
remotes advertised by S. But this could change which could make it
much simpler for clients than using the current way of passing
information about X with the `-c` option of `git clone` many times on
the command line.

Another improvement could be to not require GIT_NO_LAZY_FETCH=0 when S
and C have agreed on using S.

Christian Couder (4):
  version: refactor strbuf_sanitize()
  strbuf: refactor strbuf_trim_trailing_ch()
  Add 'promisor-remote' capability to protocol v2
  promisor-remote: check advertised name or URL

 Documentation/config/promisor.txt     |  18 ++
 Documentation/gitprotocol-v2.txt      |  37 +++++
 connect.c                             |   7 +
 promisor-remote.c                     | 228 ++++++++++++++++++++++++++
 promisor-remote.h                     |  26 ++-
 serve.c                               |  21 +++
 strbuf.c                              |  16 ++
 strbuf.h                              |  10 ++
 t/t5555-http-smart-common.sh          |   1 +
 t/t5701-git-serve.sh                  |   1 +
 t/t5710-promisor-remote-capability.sh | 192 ++++++++++++++++++++++
 trace2/tr2_cfg.c                      |  10 +-
 upload-pack.c                         |   3 +
 version.c                             |   9 +-
 14 files changed, 563 insertions(+), 16 deletions(-)
 create mode 100755 t/t5710-promisor-remote-capability.sh

Comments

Junio C Hamano July 31, 2024, 4:01 p.m. UTC | #1

Christian Couder <[e-mail]> writes:

> Earlier this year, I sent 3 versions of a patch series with the goal
> of allowing a client C to clone from a server S while using the same
> promisor remote X that S already use. See:
>
> https://lore.kernel.org/git/[e-mail]/
>
> Junio suggested to instead implement that feature using:

I actually do not see it as "instead".  The end result would be the
same when things go right.  The only "instead" part is that a protocol
exchange gives you a chance to make sure that the server can tell that
it is OK to omit objects available elsewhere and the fetcher knows
about it, instead of letting the server blindly assuming that it is
fine to omit objects.

> This patch series implements that protocol extension called
> "promisor-remote" (that name is open to change or simplification)
> which allows S and C to agree on C using X directly or not.

;-)

Taylor Blau July 31, 2024, 4:17 p.m. UTC | #2

On Wed, Jul 31, 2024 at 03:40:10PM +0200, Christian Couder wrote:
> I have tried to implement it in a quite generic way that could allow S
> and C to share more information about promisor remotes and how to use
> them.
>
> For now C doesn't use the information it gets from S when cloning.
> That information is only used to decide if C is Ok to use the promisor
> remotes advertised by S. But this could change which could make it
> much simpler for clients than using the current way of passing
> information about X with the `-c` option of `git clone` many times on
> the command line.

I left a review after carefully reading these patches. I had a couple of
technical questions and suggestions of things to change.

But it's hard to have a definite opinion about the feature overall
without seeing how it is used in practice. I didn't see anything that
made me concerned, though, so I think this is a worthwhile experimental
feature.

Thanks,
Taylor