Re: [PATCH v2 3/3] upload-pack: allow configuring a missing-action

Christian Couder [off-list ref] writes:

Alternatively, if C would pass a new option called for example
--known-promisor=X on top of all other options, then that could be Ok
too?

Why do you need a new option "--known-promisor=X" in the first
place?  Doesn't it known by the repository already and you do not
have to bother the end user to supply it from the command line, no?

In any case, 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???).  Either would work OK and I
offhand do not see much preference between the two.  

What is important is to ensure that such deliberate omission by S is
safe and acceptable by C.

Thanks.


[Footnote]

By the way, I briefly wondered: would "X" that is valid for "C" be
always valid for "S" these days?

I as "S" may prefer you as "C" to go ssh://gitlab.com/x.git but you
may only be able to go https://gitlab.com/x.git for networking
reasons.  Silly situation like that may make communicating "X"
between "S" and "C" a bit harder than we would like.  Of course this
is not a high priority issue as the user with such networking need
are probably already using url.X.insteadof to rewrite the submodule
paths recommended in .gitmodules after they clone a superproject,
iow, even if it were a problem, it is a solved one.

So, in short, yes, exchanging the known promisor "X" between "S" and
"C", regardless of which side speaks first, as long as the negotiation
makes sure both sides agree, would be a good direction to go, I
would think.