> 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.)
