Junio C Hamano <gitster@xxxxxxxxx> 于2023年4月25日周二 12:02写道： > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > Without using protocol v2, the git server needs to send a pktline > > "# service=$servicename" to the git client first. This often > > requires the git server to implement it independently, but it can > > be delegated to the `git receive-pack` and `git upload-pack` to complete > > the work proactively. Therefore, the `--show-service` option is added > > to `git receive-pack` and `git upload-pack`, which can be used to send > > the "# service=$servicename" pktline, making the logic of the git > > server more concise. > > > > Note that this `--show-service` option can only be used together with > > `--http-backend-info-refs` and it is not applicable when using protocol v2. > > > > Signed-off-by: ZheNing Hu <adlternative@xxxxxxxxx> > > --- > > The above is a very well written description of why we _can_ do > this, but it is unclear why we would _want_ to do this. What do we > gain by letting the individual services to declare "we are serving > this!"? Do we lose an extra fork & process (it does not seem to be > the case)? When I was implementing a small git http server, I wanted to delegate everything to upload-pack and receive-pack. Everything else was fine, the only thing I was not satisfied with was the need to send an additional "#service=$servername" message when the protocol is v1. To be honest, the $servername here can only be "git-upload-pack" and "git-receive-pack", and the git client does not actually do anything extra with this message. Why not let git upload-pack and git receive-pack do it? The "--show-service" option is not a functional requirement, it just simplifies the logic of the git server.
