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

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2024, 15:54 UTC
Message-ID: <xmqq34q27wzg.fsf@gitster.g>
In-Reply-To: <CAP8UFD1_aHwbhF12v-miCTWEbbgjtpjTCmkRmFHu4Vusezq6dA@mail.gmail.com>

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

Show 6 quoted lines

> 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.

Show 6 quoted lines

> "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.

Show 6 quoted lines

>> 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.