Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)

Looking back at the comments I have received in reply, I think that there were two major concerns: (i) the case where a server ACKs a client "have" line and the client forever thinks that the server has it, but it may not be the case for future servers (or future invocations of the same server), and (ii) what the client does with 2 "versions" of remote refs.

For (i), the issue already exists and as far as I can tell, this patch set does not directly impact it, positively or negatively. The "have"/"ACK" part of negotiation is kept the same - the only difference in this patch set is that wants can be specified by name instead of by SHA-1 hash. This patch set does not help the "have"/"ACK" part of negotiation, but it helps the "want" part.

For (ii), I have prepared a patch to be squashed, and extended the commit message with an explanation of what is happening. (The commit message and the patch are appended to this e-mail).

(There was also some discussion of the client being required to send exact matches in its "want-ref" lines.)

Please let me know if you have any other opinions or thoughts. It does seem to me like such a protocol update (or something similar) would help for large repositories with many ever-changing refs (like refs/changes in Gerrit or refs/pull in GitHub) - and the creation of a ref would look like a deletion depending on the order in which we access the servers in a load-balancing arrangement and the order in which those servers synchronize themselves. And deletion of refs does not work with the current protocol, but would work with a protocol that supports wildcards (like this one).

-- 8< --

fetch: send want-ref and receive fetched refs

Teach fetch to send refspecs to the underlying transport, and teach all components used by the HTTP transport (remote-curl, transport-helper, fetch-pack) to understand and propagate the names and SHA-1s of the refs fetched.

The do_fetch method in builtin/fetch.c originally had only one
remote-local ref map, generated from the already-fetched list of remote
refs. This patch introduces a new ref map generated from the list of
fetched refs. Usages of the list of remote refs or the remote-local ref
map are updated as follows:
 - check_not_current_branch (which checks that the current branch is not
   affected by the fetch) is performed both on the original ref map (to
   die before the fetch if we can, as an optimization) and on the new
   ref map (since the new ref map is the one actually applied).
 - Pruning is done based on the new ref map.
 - backfill_tags (for tag following) is performed using the original
   list of remote refs because the new list of fetched refs is not
   guaranteed to contain tag information. (Since backfill_tags performs
   another fetch, it does not need to be fully consistent with the
   just-returned packfile.)
The list of remote refs and the remote-local ref map are not otherwise
used by do_fetch or any function in its invocation chain (fetch_one and
cmd_fetch).
---
 builtin/fetch.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)