Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > ... I wonder if this is a > redundant check. --verify-objects is called to verify new packs. I do not think --verify-objects does not have anything to do with verifying the integrity of packs, whether new or old. The check is about the integrity of the *history* we _might_ already have on our side, when we find ourselves wanting to fetch up to a commit $X, whose reachability from the tips of our refs (i.e. the objects that are guaranteed to be present in our repository) is unknown, and we somehow already have the commit $X itself in the repository. We cannot just declare victory upon seeing commit $X and omit fetching the history leading to the commit, because we may or may not have its parent commit object, or the tree object that is recorded in it (it may be that we killed an HTTP walker after we fetched $X but not its parents or trees). We need to walk back from $X until we hit one of the tips of our refs, and while doing so, we also need to make sure the trees and blobs referenced from the walked commits are also healthy. As 5a48d24 (rev-list --verify-object, 2011-09-01) explains, we used to do this with --objects instead, but that check does not even make sure blobs exist [*1*] let alone checking to see if these blobs were healthy. The whole point of using --verify-objects instead of --objects is to make sure that we do not miss blob objects. [Footnote] *1* The --objects code reads the commits and trees in order to _list_ objects to the blob level, so implicitly, it validates that commits and trees reachable from the commit $X we happened to have in our repository, relying on the fact that we would error out if we fail to read them. -- 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