Re: [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing

From: Junio C Hamano <junkio@cox.net>
Date: Oct 19, 2005, 00:27 UTC
Message-ID: <7v7jcal59y.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0510181339220.3369@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 10 quoted lines

> I see you already did. Looks fine. I'd suggest limiting the commits by 
> number in mark_recent_commit_complete(), because
>
>  (a) somebody might have their clock set wrong and you don't want to walk 
>      a huge tree just because of something like that.
>  (b) you might just have imported a huge history (badly) from somewhere 
>      else
>  (c) a _lot_ can happen in five days with automated things.
>
> but yes, the approach looks very sane otherwise.

When you have several dozen commits on top of a head you fetched from the remote last time you polled them, and the remote has not updated that head since then, it may be worthwhile to have the client dig deeper to avoid asking the server.

What I am thinking is:

    - For objects our refs directly refer to, mark them COMPLETE
      as the patch I sent out.

    - See if we have any objects the remote refs refer to
      already; find the timestamp of the latest one if we have
      commits among them, and use its time as the cutoff time.

      It is likely that we have synched with them after that
      timestamp (either upload or download).  walk the commits
      from our ref, and mark *everything* that are newer than
      that timestamp.  This can turn out to be a huge walking
      but that happens on the client side.

This way I can get rid of the arbitrary 5-day window, and I do not have to invent another arbitrary number to limit the commits we walk.

In other words, let's put the burden on the client if its effort possibly can help the server.