On Wed, Oct 5, 2016 at 8:47 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Oct 04, 2016 at 02:03:58PM -0700, Stefan Beller wrote: > >> thanks for the suggestions, both git_path(..) as well as checking the config, >> this seems quite readable to me: >> >> builtin/push.c | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) > > Yeah, this seems like a good compromise to me. > > I did have one other thought, but I don't think it's worth pursuing now. > We care about finding gitlinks in objects we're pushing; is there any > process which is already looking at those objects? Genreally, the > "pack-objects" doing the push has to. Not to actually push the objects, > which often are sent blindly off disk, but to determine the set of > reachable objects in the first place. So in theory we could prepare the > list of objects to pack, and as a side effect it could say "and here are > gitlinks referenced by those objects". But that doesn't work if bitmaps > are in effect, because then we don't access the objects directly at all. > I think you could solve that by extending the bitmap format to include a > bit for gitlinks that are reachable (but not necessarily included in the > pack). > > So I don't think that's worth thinking too much about now, but it might > be an interesting optimization down the road. > > -Peff That sounds like what we'd want down the road. In my imagination the submodules of the future may live completely inside the superproject, i.e. they do not necessarily have their own URL. They can be obtained via fetching the superproject, that automagically also transmits the objects of the submodules. Thanks for the hint w.r.t. the bimaps! Stefan