Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: >> * quickfetch() that is called even before we get any object from the >> other end, to optimize the transfer when we already have what we need. >> >> The latter is the original use to protect against unconnected island of >> chain I explained in the previous message, but the former is also abot the >> same protection, in a different callchain. > > I think we can trust what we already have, so in the latter case (and > the former when the medium is a pack), --objects should suffice. Hrm, what you seem to be missing is that in the latter case, the objects we are walking to make sure the connectivity are *not* yet considered as part of "what we already have" (hence we can trust). The whole point of quickfetch is to turn these untrustworthy bits that happen to exist in our repository into a part of trustable history without having to fetch from the other side to complete them. In the former case, when we know that pack has been indexed with recent index-pack/unpack-objects that are more picky (didn't Shawn and I recently tighten them?), we may be able to do without object integrity checks. >> If we _know_ that we have checked the integrity of all the necessary >> individual objects before we start reading them in order to check the >> completeness of the history, there is an opportunity to optimize by >> teaching --verify-objects paths to optionally be looser than it currently >> is, to avoid checking the object integrity twice. > > Ok, will cook something. The reason I raised it is because > --verify-objects --all on git.git could take ~1m10s, but if we assume > object integrity is fine and skip it, it could drop to 10s (I suspect > --objects gives the same number). That is a big assumption that I personally do not want to sacrifice the integrity of my history on. I would 100% agree with the above with s/if we assume/if we know/, though. -- 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