From: Junio C Hamano <firstname.lastname@example.org> To: Christian Couder <email@example.com> Cc: Jonathan Tan <firstname.lastname@example.org>, git <email@example.com>, Jeff Hostetler <firstname.lastname@example.org>, Ben Peart <email@example.com> Subject: Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches) Date: Tue, 03 Oct 2017 17:50:42 +0900 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAP8UFD1WiceKDX9s0hszXXKy+TOxAOvHZyr002HMYkkgbFgD7w@mail.gmail.com> (Christian Couder's message of "Tue, 3 Oct 2017 08:15:33 +0200") Christian Couder <email@example.com> writes: > Could you give a bit more details about the use cases this is designed for? > It seems that when people review my work they want a lot of details > about the use cases, so I guess they would also be interesting in > getting this kind of information for your work too. > > Could this support users who would be interested in lazily cloning > only one kind of files, for example *.jpeg? I do not know about others, but the reason why I was not interested in finding out "use cases" is because the value of this series is use-case agnostic. At least to me, the most interesting part of the series is that it allows you to receive a set of objects transferred from the other side that lack some of objects that would otherwise be required to be here for connectivity purposes, and it introduces a mechanism to allow object transfer layer, gc and fsck to work well together in the resulting repository that deliberately lacks some objects. The transfer layer marks the objects obtained from a specific remote as such, and gc and fsck are taught not to try to follow a missing link or diagnose a missing link as an error, if a missing link is expected using the mark the transfer layer left. and it does so in such a way that it is use-case agnostic. The mechanism does not care how the objects to be omitted were chosen, and how the omission criteria were negotiated between the sender and the receiver of the pack. I think the series comes with one filter that is size-based, but I view it as a technology demonstration. It does not have to be the primary use case. IOW, I do not think the series is meant as a declaration that size-based filtering is the most important thing and other omission criteria are less important. You should be able to build path based omission (i.e. narrow clone) or blobtype based omission. Depending on your needs, you may want different object omission criteria. It is something you can build on top. And the work done on transfer/gc/fsck in this series does not have to change to accommodate these different "use cases".
next prev parent reply other threads:[~2017-10-03 8:50 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-29 20:11 Jonathan Tan 2017-09-29 20:11 ` [PATCH 01/18] fsck: introduce partialclone extension Jonathan Tan 2017-09-29 20:11 ` [PATCH 02/18] fsck: support refs pointing to promisor objects Jonathan Tan 2017-09-29 20:11 ` [PATCH 03/18] fsck: support referenced " Jonathan Tan 2017-09-29 20:11 ` [PATCH 04/18] fsck: support promisor objects as CLI argument Jonathan Tan 2017-09-29 20:11 ` [PATCH 05/18] index-pack: refactor writing of .keep files Jonathan Tan 2017-09-29 20:11 ` [PATCH 06/18] introduce fetch-object: fetch one promisor object Jonathan Tan 2017-09-29 20:11 ` [PATCH 07/18] sha1_file: support lazily fetching missing objects Jonathan Tan 2017-10-12 14:42 ` Christian Couder 2017-10-12 15:45 ` Christian Couder 2017-09-29 20:11 ` [PATCH 08/18] rev-list: support termination at promisor objects Jonathan Tan 2017-09-29 20:11 ` [PATCH 09/18] gc: do not repack promisor packfiles Jonathan Tan 2017-09-29 20:11 ` [PATCH 10/18] pack-objects: rename want_.* to ignore_.* Jonathan Tan 2017-09-29 20:11 ` [PATCH 11/18] pack-objects: support --blob-max-bytes Jonathan Tan 2017-09-29 20:11 ` [PATCH 12/18] fetch-pack: support excluding large blobs Jonathan Tan 2017-09-29 20:11 ` [PATCH 13/18] fetch: refactor calculation of remote list Jonathan Tan 2017-09-29 20:11 ` [PATCH 14/18] fetch: support excluding large blobs Jonathan Tan 2017-09-29 20:11 ` [PATCH 15/18] clone: " Jonathan Tan 2017-09-29 20:11 ` [PATCH 16/18] clone: configure blobmaxbytes in created repos Jonathan Tan 2017-09-29 20:11 ` [PATCH 17/18] unpack-trees: batch fetching of missing blobs Jonathan Tan 2017-09-29 20:11 ` [PATCH 18/18] fetch-pack: restore save_commit_buffer after use Jonathan Tan 2017-09-29 21:08 ` [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches) Johannes Schindelin 2017-10-02 4:23 ` Junio C Hamano 2017-10-03 6:15 ` Christian Couder 2017-10-03 8:50 ` Junio C Hamano [this message] 2017-10-03 14:39 ` Jeff Hostetler 2017-10-03 23:42 ` Jonathan Tan 2017-10-04 13:30 ` Jeff Hostetler
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).