Re: [PATCH 3/4] Add 'promisor-remote' capability to protocol v2
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 20, 2024, 17:01 UTC
- Message-ID
- <xmqqzfp786xe.fsf@gitster.g>
- In-Reply-To
- <CAP8UFD04M2m0_Y5uVpau2BTsJWLq85fvBCVz2VYEcx902dXWBA@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 19 quoted lines
> I agree that it's more useful the other way though. That is for a > server to know that the client has the capability but might not want > to use it. > > For example, when C clones without using X directly, it can be a > burden for S to have to fetch large objects from X (as it would use > precious disk space on S, and unnecessarily duplicate large objects). > So S might want to say "please use a newer or different client that > has the 'promisor-remote' capability" if it knows that the client > doesn't have this capability. If S knows that C has the capability but > didn't configure it or doesn't want to use it, it could instead say > something like "please consider activating the 'promisor-remote' > capability by doing this and that to avoid burdening this server and > get a faster clone". > > Note that the client might not be 'git'. It might be a "compatible" > implementation (libgit2, gix, JGit, etc), so using the version passed > in the "agent" protocol capability is not a good way to detect if the > client has the capability or not.
It is none of S's business to even know about C's "true" capability, if C does not want to use it with S. I do not quite find the above a credible justification.