Zsolt Imre <imrexzsolt@xxxxxxxxx> writes:
> I'm not entirely sure if this is a bug or I am missing something,
> but I thought I would share in the hope someone can help out. I'm
> playing around with Git and trying to implement a git server that
> communicates over HTTP and supports Git protocol version 2 *only*.
>
> When I `clone` a repository, the Git client (version 2.43.0),
> after fetching the capabilities using protocol version 2, it
> proceeds to fetch the refs, again, via protocol version 2 using
> the `ls-refs` command. However, when I try to `push` my changes
> to the repo, the Git client refuses to use protocol version 2 and
> tries to obtain the ref list using protocol version 0, even if I
> pass in the `-c protocol.version=2` command line argument.
Given that v0 and v1 in the push direction behave exactly the same,
and there has been no need to add features that were not supportable
in v1 in the push direction, it is not surprising to see this code
int cmd_send_pack(int argc, const char **argv, const char *prefix)
{
...
switch (discover_version(&reader)) {
case protocol_v2:
die("support for protocol v2 not implemented yet");
break;
in https://github.com/git/git/blob/master/builtin/send-pack.c#L282
and also
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
...
switch (determine_protocol_version_server()) {
case protocol_v2:
/*
* push support for protocol v2 has not been implemented yet,
* so ignore the request to use v2 and fallback to using v0.
*/
break;
in https://github.com/git/git/blob/master/builtin/receive-pack.c#L2538
that tells the receiving end to demote "v2" request down to "v0",
and have the pushing end honor that choice.
What specifically did you want to gain by using protocol version 2
in the "push" direction that you cannot do with the current
versions?
