Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack

[Junio C Hamano <junkio@cox.net>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> +		if (insert)
> +			insert_by_date(commit, &rev_list);
> +		else
>  			commit_list_insert(commit, &rev_list);

Hmph.  I do not think insert_by_date and commit_list_insert on
the same commit_list would play well together, since the former
assumes that the list is already sorted by age (i.e. younger ones
near the head, older ones close to the tail).

But you are right.  If you made 20 commits on top of my "master"
branch head, we should send those 20 (and the commit you based
on your changes, which the other end has), way before sending
the ancient v0.99 tag.  Probably, we should never be sending
v0.99 tag as "have" if we are going to send your "master" branch
head, since the commit that tag refers to is reachable by your
"master" branch head but there are a lot more commit between
them, some of which will give us better "common" selected, and
that v0.99 tag is what the other end said they have so is known
to be ACKed if sent.

Although we are doing a traversal on the fetch side to figure
out the commit ancestry chain, I think we are not fully
utilizing the information we receive from the other end.
Typically we pull specific heads only, so get_remote_heads()
culls the information about remote refs and you would not have a
chance to know that v0.99 tag you have in your .git/refs/tags is
something the remote also has, unless you asked for that
particular tag.  I wonder if we can take advantage of that
information without discarding it.  For example,
get_remote_heads() itself knows the object name of v0.99.8 tag
and the object name of the commit the tag refers to, and you
have those objects locally already.  If you have many local
branches, and v0.99.8 commit is reachable from the heads of all
of your local branches, then you should be able to tell that you
do not have to (and you do not want to) send "have" for v0.99.7
and older tags even though they are also in your .git/refs/,
since you know they are all reachable from v0.99.8 commit and
likely to be worse common than v0.99.8.  The best common is
somewhere between v0.99.8 and the tips of your local branches.

This is a minor nit but I think you no longer need to have the
rev_list_end in this version.  It is only used to maintain
itself and not for any other purpose as far as I can see.