Re: [WIP v2 2/2] pack-objects: support --blob-max-bytes

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 15, 2017, 21:03 UTC
Message-ID: <20170615140305.4f79f5f0@twelve2.svl.corp.google.com>
In-Reply-To: <14b1fbb0-d4fb-1dd3-936c-deea6d20a99b@jeffhostetler.com>

On Thu, 15 Jun 2017 16:28:24 -0400 Jeff Hostetler <git@jeffhostetler.com> wrote:

Show 7 quoted lines

> I agree with Peff here.  I've been working on my partial/narrow/sparse
> clone/fetch ideas since my original RFC and have come to the conclusion
> that the server can do the size limiting efficiently, but we should
> leave the pathname filtering to the client.  That is, let the client
> get the commits and trees and then locally apply pattern matching,
> whether that be a sparse-checkout definition or simple ".git*"
> matching and then make a later request for the "blobs of interest".

This means that the client would need to inflate all the trees it received, but that might not be that bad.

Show 8 quoted lines

> Whether we "fault-in" the missing blobs or have a "fetch-blobs"
> command (like fetch-pack) to get them is open to debate.
> 
> There are concerns about the size of the requested blob-id list in a
> fetch-blobs approach, but I think there are ways to say I need all
> of the blobs referenced by the directory /foo in commit xxxx (and
> optionally, that aren't present in directory /foo in commit yyyy
> or in the range yyyy..xxxx).  (handwave)

Unless the server no longer has the relevant commit (e.g. because a branch was rewound), but even then, even if we only sent blob hashes, the list would be probably much smaller than the downloaded pack anyway, so things might still be OK.