Re: [PATCH v3 03/11] promisor-remote: implement promisor_remote_get_direct()

[Christian Couder <christian.couder@gmail.com>]

On Wed, Mar 13, 2019 at 5:24 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:

> > +int promisor_remote_get_direct(const struct object_id *oids, int oid_nr)
> > +{
> > +     struct promisor_remote *o;
> > +
> > +     promisor_remote_init();
> > +
> > +     for (o = promisors; o; o = o->next) {
> > +             if (fetch_objects(o->remote_name, oids, oid_nr) < 0)
> > +                     continue;
> > +             return 0;
>
> Suppose the caller asks to fetch 3 objects, A, B and C, from two
> promisors.  The first promisor can give you A and B but cannot give
> you C.  The second promisor only can give you C.
>
> Does fetch_objects() return failure after attempting to fetch A, B
> and C from the first promisor?

Yes, I think it should still send the objects it has and then fail.

Maybe it doesn't work like this right now (I haven't checked), or
maybe the failure should be different than a regular failure. In those
cases I can maybe improve on that in a later iteration.

> Then we go on to the second promisor
> but do we ask all three?  That would mean the second promisor will
> also fail because it cannot give you A and B, and then the whole
> thing would fail.  It would be nicer if the mechanism would allow us
> to fetch what is still missing from later promisor, perhaps.

Yeah, I implemented fetching only what is still missing in v4.

> As the original "fetch" protocol only allows you to fetch a pack
> with everything you asked for in it, instead of feeding you a pack
> with best effort, I think the answer to the above is "it is very
> hard to improve over what we have here", but people may have
> interesting ideas ;-)

I think we should make it best effort when acting as a promisor
remote. I will take a look at that.

> > +     }
> > +
> > +     return -1;
> > +}
> > +
>
> Adding trailing blank line at the end?

Removed.