Re: [PATCH v2 3/3] upload-pack: allow configuring a missing-action

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

> It's basically the same as when a regular clone or a partial clone or
> a clone using bundle-uri fails or when using a regular bundle fails.
> If it failed because the remote was not properly configured, then that
> config can be fixed. If it fails because the remote doesn't have some
> objects, then maybe the missing objects can be transferred to the
> remote. And so on.

> The feature doesn't create any new kind of failure.

> "it would be nice if there was a capability for the client to say
> that it would like the server to give it information about the
> promisor that it could use, so that the user doesn't have to pass all
> the "remote.my_promisor.XXX" config options on the command like."
>
> and by saying that this could be added later.

Can such an update happen transparently, or does it need changes to
end-user experience?  It is of dubious value to leave the initial
series be incomplete if the latter is the case.

>> Without knowing that, it cannot safely decide that it does not
>> have to send objects that can be obtained from X to C.
>
> In the above command C is asking for a partial clone, as it uses a
> --filter option. This means that C knows very well that it might not
> get from S all the objects needed for a complete object graph.

Hmph.  If C asks a partial clone and S is willing to be the promisor
for C, S is essentially saying that it will serve C any objects on
demand that are reachable from any object it served C in the past,
forever, no?  It might not get from S initially all the objects, but
if it wants later, S promises to let C have them.


> Again when using a regular partial clone omitting the same set of
> objects, C also requests some objects that S doesn't have.  And
> this is not considered an issue or something irresponsible. It
> already works like this.

"S doesn't have" is because S has pruned objects that it shouldn't
have in order to keep the promise it made earlier to C, right?  If
that is the case, I would very much say S is being irresponsible in
that case.

> And then C still has the possibility to configure X as a
> promisor remote and get missing objects from there. So why is it Ok
> when it's done in several steps but not in one?

You are right that S can decide to unilaterally break the promise it
made C, so this update is not making it any worse than giving users
a broken implementation of promisor remotes.  I wouldn't call it OK,
though.

If somebody identifies that even without this series, S can lead to
repository corruption at C by pruning objects it does need to keep
its promise to C, the next action I expect from healthy project is
to try coming up with a mechanism to make it less likely that such a
pruning happens by accident (e.g., by noticing allowAnySHA1InWant as
a sign that the repository has promised others to serve anything
that used to be reachable from anything it historically served,
disabling repack "-d" and instead send the currently unreachable
objects to an archived pack, and something equally silly like that).
It certainly is not to add a new mechanism to make it even easier to
configure S to break promised it made to C.

So, I dunno.