Martin Koegler <mkoegler@xxxxxxxxxxxxxxxxx> writes: > To introduce a object with one of its linked objects missing, left it > out of the pack and push it into the repository. unpack-objects will > unpack all objects and fail updating the ref (but leave all objects in > the repository). As second step, simply send a ref update request, > which should succed, as the object is present in the repository. Your "ref update request" exploit does not work because your understanding of how we decide to allow updating a ref is flawed. We do not blindly update a ref to a commit only because we happen to have that commit. We require that commit to reach existing tips of refs without break. The logic is in quickfetch() in builtin-fetch.c. This stronger validation is necessary to deal with any failed transfer by http walkers, so it is nothing unusual nor new. They walk from the latest commits that exist on the other side, and their object transfer can be interrupted before they transfer enough older commits to make the history connected with what we already had. In such a case we obviously do not update any ref. And when we re-run the same request, we do not say "Ah, we have the tip in the object database, so we will update the ref to it". That is why I said requiring connectivity is a good idea, but keeping them in core is a misguided waste of memory. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html