Linus Torvalds <torvalds@linux-foundation.org> writes:

quoted text
> So I think that the way to verify a superproject is:
>
>  - fsck each and every project totally independently. This is something 
>    you have to do *anyway*.
>
>  - either as you fsck, or as a separate phase after the fsck, just 
>    traverse the trees and spit out "these are the SHA1's of subprojects"
>
>  - finally, just go through the list of SHA1's (after every project has 
>    been fsck'd) and verify that they exist (since if they exist, they will 
>    have everything that is reachable from them, as that's one of the 
>    things that the *local* fsck verifies)

The small detail in the last step is wrong, though.  Even if
they EXIST, they may be isolated commits that are note connected
to refs, and fsck in the repository would not have warned about
unreachable trees from such unconnected commits.  So you would
need to do a reachability from these commits to the refs in the
subproject.

This would be similar to the quick-fetch topic I sent out a
couple of patches for, that implements logic to skip fetching
objects from your alternate.  You would have rev-list --objects
traverse from them with "--not --all" in the subproject
repository and make sure it does not trigger "I could not list
all objects reachable from the commits you wanted because such
and such tree/blob are missing".

    That reminds me of one thing I haven't verified.  I am not
    absolutely sure that rev-list --objects makes sure that
    blobs it lists exist (trees are checked as it needs to read
    them, and if they are missing or corrupt it would notice and
    barf).  When it is used for the purpose of this "subproject
    boundary fsck" and the quick-fetch, it should.  Perhaps a
    specialized option to check deeper than usual is needed.  I
    dunno.

quoted text
> Notice? At no point do you actually need to do a "global fsck". You can do 
> totally independent local fsck's, and then a really cheap test of 
> connectedness once those fsck's have completed.

This is still true.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html