Re: [PATCH] Do not call git-rev-list from git-fetch-pack

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

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

> +	   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.