On Fri, 15 Sep 2017 13:24:50 +0200 Christian Couder <christian.couder@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ 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@xxxxxxxxxx/ > > 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.
