On Sun, Feb 26, 2012 at 3:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. "rev-list --objects" does check for blob existence, in finish_object(). On the well-formedness, unless I'm mistaken, --verify-objects is _always_ used in conjunction with index-pack. --verify-object is not even documented. index-pack makes sure all (new) object signatures reflect their content. Commit and tree content are validated by rev-list walking them. So at least when --verify-objects is used with index-pack, I don't see the point rehashing every new object _again_. > [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. -- Duy -- 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