On Tue, Jul 23, 2013 at 6:41 AM, Philip Oakley <philipoakley@xxxxxxx> wrote: > From: "Nguyễn Thái Ngọc Duy" <pclouds@xxxxxxxxx> > 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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html