Christian Couder <christian.couder@xxxxxxxxx> 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.
