Re: optimising a push by fetching objects from nearby repos

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> But what I was looking for was validation from git.git folks of the idea
>> of replicating what "git clone -l" does, for an *existing* repo.
>>
>> For example, I'm assuming that bringing in only the objects -- without
>> any of the refs pointing to them, making them all dangling objects --
>> will still allow the optimisation to occur (i.e., git will still say "oh
>> yeah I have these objects, even if they're dangling so I won't ask for
>> them from the pusher" and not "oh these are dangling objects; so I don't
>> recognise them from this perspective -- you'll have to send me those
>> again").
>
> So here is an educated guess by a git.git folk.  I haven't read the
> codepath for some time, so I may be missing some details:
>
>   - The set of objects sent over the wire in "push" direction is
>     determined by the receiving end listing what it has to the
>     sending end, and then the sending end excluding what the
>     receiving end told that it already has.
>
>   - The receiving end tells the sending end what it has by showing
>     the names of its refs and their values.
>
> Having otherwise dangling objects in your object store alone will
> not make them reachable from the refs shown to the sending end.  But
> there is another trick the receiving end employes.
>
>   - The receiving end also includes the refs and their values that
>     appear in the repository it borrows objects from its alternate
>     repositories, when it tells what objects it already has to the
>     sending end.
>
> So what you "assumed" is not entirely correct---bringing in only the
> objects will not give you any optimization.
>
> But because we infer from the location of the object store
> (i.e. "objects" directory) where the refs that point at these
> borrowed objects exist (i.e. in "../refs" relative to that "objects"
> directory) in order to make sure that we do not have to say "oh
> these are dangling but we know their history is not broken", we
> still get the same optimisation.