Johannes SchindelinHi,
I reported a while ago that a fetch downloaded objects which were already in the repository. While that was true, it was not the whole truth: This only happened with multi-head fetch.
As far as I can tell, what happened was this:
- fetch-pack connected to the server - it asked correctly for the remote refs - it then opened a (local) pipe to git-rev-list - it sent quite a few refs from that pipe over the wire - on the other side, upload-pack marked these refs as "fetcher got those" - since upload-pack has a limit on that list (only 16) it soon said STFU - it turned out that quite a few common refs were not yet marked - so upload-pack would upload these
The reason is that git-rev-list would happily output parents of refs which were already acknowledged by upload-pack to be common refs.
I just sent out a patch which makes this irrelevant for the case that most or all of these heads are already fetched.
Now, to really solve the multi-head problem, which really is the problem "how to find the edges of the common commits", I propose the following:
For each remote ref known to be not in the local repository, find the 1st, 2nd, 4th, 8th, ... parents. Send these to upload-pack to be marked. For each ack'ed ref (i.e. remote side also has it), do a binary search to find the edge (i.e. the youngest common ref) on that DAG branch.
(To ease the burden on the server side, one coul mark only the edges as stop gaps for upload-pack. However, it might make things too complicated.)
Of course, the trick is to do that asynchronously, so that the network bandwidth is used optimally. This means that not each ack'ed ref leads to a binary search, but only those refs where no descendant was ack'ed.
BTW this does not need any change of the protocol. In fact, it only needs a change to fetch-pack.
I'd also increase MAX_HAS in upload-pack.
Ciao, Dscho
