Re: [PATCH] Do not call git-rev-list from git-fetch-pack
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 21, 2005, 08:51 UTC
- Message-ID
- <7virvrw8w1.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0510210413210.26388@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 10 quoted lines
> + Branch1 has 40 commits since it last merged with branch2, > + and branch2 has 2 more commits since then. > + > + On the other end, branch1 is up-to-date, but branch2 is not. > + When fetching branch1, the 40 commits get sent, the first > + is acknowledged as common, and the local head of branch2 > + never gets sent. > + > + As a consequence, the whole history of branch2 > + (git-rev-list branch2 ^branch1) gets packed and transmitted.
Arrrgggggggh. The description above captures the essense of the problem very well, but faking dates and still popping by recency looks like a really ugly hack to me.
Wouldn't it be cleaner if you traversed commits starting from local refs, and assign distance from the tip of the branch to each object (use generic object->util field for it), and maintain an object_list that is sorted by depth, similar to commit_list sorted by commit date? Then you can pop from the list by depth, closer to tip first, and tell the other end that you have branch1, branch2, branch1^, branch2^, branch1~2, branch2~1,... which is the order the above situation benefits from.