Re: [PATCH 0/2] Skip ls-refs if possible for HTTP

[Jonathan Tan <jonathantanmy@google.com>]

> This probably is totally off-tangent, but do any of these "let's
> advertise fewer" changes at the protocol level have to take into
> account the use of --prune option on the client side?

I don't think so. According to what I understand from the documentation,
the prune option prunes based on the RHS of the refspec, and it doesn't
affect anything non-matching. When we advertise fewer, the only refs
that are missing are those that are non-matching anyway.

Some experimentation seems to show that that is the case also:

$ git init one
[snip]
$ git -C one commit --allow-empty -m x
[master (root-commit) 67056ac] x
$ git -C one branch maste
$ git -C one branch other
$ git clone "$(pwd)/one" two
Cloning into 'two'...
done.
$ git -C one branch -d maste
Deleted branch maste (was 67056ac).
$ git -C two checkout --detach HEAD
HEAD is now at 67056ac x
$ GIT_TRACE_PACKET=1 git -c protocol.version=2 -C two fetch --prune origin refs/heads/m*:refs/remotes/origin/m*
[snipped lots of stuff; basically, only refs/heads/master is sent]
10:15:46.308264 pkt-line.c:80           packet:        fetch> ref-prefix refs/heads/m
10:15:46.308276 pkt-line.c:80           packet:        fetch> ref-prefix refs/tags/
10:15:46.308523 pkt-line.c:80           packet:        fetch< 67056ac6d07814334716df760054ac5bec05b66a refs/heads/master
From /usr/local/google/home/jonathantanmy/tmp/g/one
 - [deleted]         (none)     -> origin/maste
$ git -C two for-each-ref
67056ac6d07814334716df760054ac5bec05b66a commit	refs/heads/master
67056ac6d07814334716df760054ac5bec05b66a commit	refs/remotes/origin/HEAD
67056ac6d07814334716df760054ac5bec05b66a commit	refs/remotes/origin/master
67056ac6d07814334716df760054ac5bec05b66a commit	refs/remotes/origin/other

(Notice that refs/remotes/origin/other is untouched.)