Subject: Re: [PATCH v10 2/8] receive-pack: add new proc-receive hook

From: Junio C Hamano <[email-masked]>
Date: Mon, 13 Apr 2020 14:50:51 -0700

Jiang Xin <[email-masked]> writes:

> Before making a decision, we must consider some limitations or backward
> compatibility issues.  See the limitations from following code snippet
> of "send-pack.c" and "transport.c":
> ...
> The sideband message stream (stderr of 'proc-receive') will be sent
> directly to the client.  If the client is a very old version of git,
> is is still safe?

These made your assumptions clear to me, I think.

I was expecting that the protocol was purely between receive-pack
and the hook and the communication back to the "push" side was done
by receive-pack, AFTER receive-pack finished talking with the hook,
reading and understanding what the hook did.  And with that
expectation, the protocol to the hook is free of "compatibility"
concern and does not have to be constrained to "one report packet,
which may have to carry multiple updates if the hook updates
multiple refs in response to a single update request packet".

But if you are letting the hook talk directly to the "push" side,
without "receive-pack" even snooping/understanding what is going on,
sure, I can understand why you have to put such a limitation to the
protocol to the hook or use/unuse of the side-band.

I actually think we would need some update (new capability, perhaps)
to the protocol between "push" and "receive-pack" when we want to
fully support things like "you tried to push commit A to
'refs/for/X'; 'refs/for/X' is not created nor updated, but instead
'refs/heads/X' has been updated to commit B, which got created using
info in A".  A partial support can be done by just pretending that
the proposed update for 'refs/for/X' succeeded and nothing else
happened, and that may be a perfectly usable initial version.  But I
would suspect that we eventually would want to be able to tell the
"git push" a bit more, and at that point, we'd probably want new
capabilities between "push" and "receive-pack".

I think we should retain fairly strict control over the vocabulary
used by "receive-pack" to explain what happened on "the server side"
to the client, to avoid fracturing the ecosystem.  With "hook's
output is sent pass-thru back to the client" design, you'd allow a
proprietary proc-receive hook to express what it did in a way that
only a matching proprietary variant of "git push" can understand,
which I do not think is a good thing.

Thanks.