From: Junio C Hamano <email@example.com> To: Jeff King <firstname.lastname@example.org> Cc: Christian Couder <email@example.com>, Stefan Beller <firstname.lastname@example.org>, git <email@example.com>, Ben Peart <Ben.Peart@microsoft.com>, Jonathan Tan <firstname.lastname@example.org>, Duy Nguyen <email@example.com>, Mike Hommey <firstname.lastname@example.org>, Lars Schneider <email@example.com>, Eric Wong <firstname.lastname@example.org>, Christian Couder <email@example.com>, Jeff Hostetler <firstname.lastname@example.org>, Eric Sunshine <email@example.com>, Beat Bolli <firstname.lastname@example.org> Subject: Re: [PATCH v4 9/9] Documentation/config: add odb.<name>.promisorRemote Date: Wed, 26 Sep 2018 11:11:45 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20180926041222.GA743@sigill.intra.peff.net> (Jeff King's message of "Wed, 26 Sep 2018 00:12:22 -0400") Jeff King <firstname.lastname@example.org> writes: >> I do not think "sources that are not git repositories" is all that >> interesting, unless they can also serve as the source for ext:: >> remote helper. And if they can serve "git fetch ext::...", I think >> they can be treated just like a normal Git repository by the >> backfill code that needs to lazily populate the partial clone. > > I don't know about that. Imagine I had a regular Git repo with a bunch > of large blobs, and then I also stored those large blobs in something > like S3 that provides caching, geographic locality, and resumable > transfers. > > It would be nice to be able to say: > > 1. Clone from the real repo, but do not transfer any blobs larger than > 10MB. > > 2. When you need a blob, check the external odb that points to S3. Git > cannot know about this automatically, but presumably you would set > a few config variables to point to an external-odb helper script. > > 3. If for some reason S3 doesn't work, you can always request it from > the original repo. That part _doesn't_ need extra config, since we > can assume that the source of the promisor pack can feed us the > extra objects. > > But you don't need to ever be able to "git fetch" from the S3 repo. > > Now if you are arguing that the interface to the external-odb helper > script should be that it _looks_ like upload-pack, but simply advertises > no refs and will let you fetch any object, that makes more sense to me. > It's not something you could "git clone", but you can "git fetch" from > it. Yup. The lazy backfill JTan has, if I understand correctly, only wants "Please give me this and that object" and use of "upload-pack" is an implementation detail. Over the existing Git protocols, you may implement it as sending these object names as "want" and perhaps restrict the traversal (if there is a "want" object that is commit) by giving some commits as "have", i.e. "upload-pack" may not be the best model for the other side, but that is what we have readily available. I was hoping that the way we take to move forward is to enhance that interface so that we can use different "object store" backends as needed, to satisfy needs from both parties.
next prev parent reply other threads:[~2018-09-26 18:11 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-02 6:14 [PATCH v4 0/9] Introducing remote ODBs Christian Couder 2018-08-02 6:14 ` [PATCH v4 1/9] fetch-object: make functions return an error code Christian Couder 2018-08-02 6:14 ` [PATCH v4 2/9] Add initial remote odb support Christian Couder 2018-08-02 6:14 ` [PATCH v4 3/9] remote-odb: implement remote_odb_get_direct() Christian Couder 2018-08-02 6:15 ` [PATCH v4 4/9] remote-odb: implement remote_odb_get_many_direct() Christian Couder 2018-08-02 6:15 ` [PATCH v4 5/9] remote-odb: add remote_odb_reinit() Christian Couder 2018-08-02 6:15 ` [PATCH v4 6/9] Use remote_odb_get_direct() and has_remote_odb() Christian Couder 2018-08-02 6:15 ` [PATCH v4 7/9] Use odb.origin.partialclonefilter instead of core.partialclonefilter Christian Couder 2018-08-02 6:15 ` [PATCH v4 8/9] t0410: test fetching from many promisor remotes Christian Couder 2018-08-02 6:15 ` [PATCH v4 9/9] Documentation/config: add odb.<name>.promisorRemote Christian Couder 2018-08-02 22:55 ` Stefan Beller 2018-09-25 8:07 ` Christian Couder 2018-09-25 22:31 ` Junio C Hamano 2018-09-26 4:12 ` Jeff King 2018-09-26 13:44 ` Taylor Blau 2018-09-26 18:11 ` Junio C Hamano [this message] 2018-10-16 17:43 ` Jonathan Nieder 2018-10-16 22:22 ` Jonathan Tan 2018-10-19 0:01 ` Junio C Hamano 2018-10-19 0:33 ` Jonathan Nieder 2018-10-19 2:55 ` Junio C Hamano 2018-10-31 6:28 ` Christian Couder 2018-11-01 21:16 ` Jeff King
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Ben.Peart@microsoft.com \ --email@example.com \ --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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v4 9/9] Documentation/config: add odb.<name>.promisorRemote' \ /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).