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

From: Junio C Hamano <junkio@cox.net>
Date: Oct 25, 2005, 23:32 UTC
Message-ID: <7vll0hcgv3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0510251104470.24174@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 15 quoted lines

> On Tue, 25 Oct 2005, Junio C Hamano wrote:
>
>> 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.
>
> You´re right. Complete common refs are sent even if they are ancestors of 
> other complete common refs. I´ll think about that.

I think you should be able to do something similar to what git-show-branch --independent does, except that the current show-branch implementation sucks. It wastes one-bit per ref head, which is not too bad if we deal only with branches (who would sanely keep more than 29 branches in a repo except Jeff ;-) but is useless for a repository with any reasonable history and a lot of tags.