Jiang Xin <worldhello.net@xxxxxxxxx> 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.
