On Tue, Jul 23, 2013 at 6:41 AM, Philip Oakley <philipoak...@iee.org> wrote:
> From: "Nguyễn Thái Ngọc Duy" <pclo...@gmail.com>
> Subject: [PATCH v2 00/16] First class shallow clone
> It's nice to see that shallow can be a first class clone.
> Thinking outside the box, does this infrastructure offer the opportunity to
> maybe add a date based depth option that would establish the shallow
> watermark based on date rather than count. (e.g. the "deepen" SP depth could

I've been carefully avoiding the deepen issues because, as you see,
it's complicated. But no, this series does not enable or disable new
deeepen mechanisms. They can always be added as protocol extensions.
Still thinking if it's worth exposing a (restricted form of) rev-list
to the protocol..

> have an alternate with a leading 'T' to indicate a time limit ratherv than
> revision count - I'm expecting such a format would be an error for existing
> servers).
> My other thought was this style of cut limit list may also allow a big file
> limit to do a similar process of listing objects (e.g. blobs) that are
> size-shallow in the repo, though it maybe a long list on some repos, or with
> a small size limit.

This one, on the other hand, changes the "shape" of the repo (now with
holes) and might need to go through the same process we do with this
series. Maybe we should prepare for it now. Do you have a use case for
size-based filtering? What can we do with a repo with some arbitrary
blobs missing? Another form of this is narrow clone, where we cut by
paths, not by blob size. Narrow clone sounds more useful to me because
it's easier to control what we leave out.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to