From: Jonathan Tan Date: Fri, 15 Sep 2017 20:54:52 GMT Subject: Re: [PATCH v5 25/40] external-odb: add 'get_direct' support Message-ID: <20170915135452.4289d591@twelve2.svl.corp.google.com> In-Reply-To: On Fri, 15 Sep 2017 13:24:50 +0200 Christian Couder wrote: > > There are still some nuances. For example, if an external ODB provides > > both a tree and a blob that the tree references, do we fetch the tree in > > order to call "have" on all its blobs, or do we trust the ODB that if it > > has the tree, it has all the other objects? In my design, I do the > > latter, but in the general case where we have multiple ODBs, we might > > have to do the former. (And if we do the former, it seems to me that the > > connectivity check must be performed "online" - that is, with the ODBs > > being able to provide "get".) > > Yeah, I agree that the problem is more complex if there can be trees > or all kind of objects in the external odb. > But as I explain in the following email to Junio, I don't think > storing other kind of objects is one of the most interesting use case: > > https://public-inbox.org/git/CAP8UFD3=nuTRF24CLSoK4HSGm3nxGh8SbZVpMCg7cNcHj2zkBA@mail.gmail.com/ If we start with only blobs in the ODB, that makes sense (the ODB will need to supply a fast enough "list" or "have", but, as you wrote before, a mechanism like fetching an additional ref that contains all the necessary information whenever we fetch refs would be enough). I agree that it would work with existing use cases (including yours). > > (Also, my work extends all the way to fetch/clone [1], but admittedly I > > have been taking it a step at a time and recently have only been > > discussing how the local repo should handle the missing object > > situation.) > > > > [1] https://public-inbox.org/git/cover.1499800530.git.jonathantanmy@google.com/ > > Yeah, I think your work is interesting and could perhaps be useful for > external odbs as there could be situations that would be handled > better using your work or something similar. Thanks.