Re: Question about how git determines the minimum packfile for a push.

From: Jeff King <peff@peff.net>
Date: Apr 28, 2015, 05:33 UTC
Message-ID: <20150428053332.GH24580@peff.net>
In-Reply-To: <E51394554A503C4E852F9BEE46B03E8D01E4E784@TI-ODIN.tasernet.com>

On Mon, Apr 27, 2015 at 12:41:28AM +0000, Brad Litterell wrote:

> Is it possible git is not computing the delta correctly?  Or does git
> only look at the top-level commit objects to figure out what to
> include in the push packfile?

It's the latter. Junio mentioned that "push" is not as thorough about finding common ancestors as "fetch", but I think even "fetch" would have the same problem.

If we know that the other side has commit X, we know that it also has X~3, and we also know that it has every tree and blob mentioned by X~3. But it's much too expensive to open up every tree to generate the full set of reachable objects; for the Linux kernel, that is something like 45 seconds of CPU time, just to find out "oh, we only need to send 5 objects".

This works pretty well in practice, because trees and blobs from older history don't tend to resurface verbatim. But as you noticed, there are certain cases where it does happen, and the number of objects affected can be quite large (to the point that sending the extra objects is much more expensive than the cost of doing the extra tree traversal). Unfortunately there is no "look harder" option you can give to "git push" when you, as the user, realize this is happening.

If you have pack reachability bitmaps, they do produce a more thorough answer. So probably:

  git repack -adb
  git push

on the client would make this work as you expect.

> Will it upload the larger pack only to have the server correctly handle the duplicates?

Yes, the receiving side should correctly handle the duplicates.

-Peff