Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

From: Junio C Hamano <junkio@cox.net>
Date: Apr 12, 2007, 00:34 UTC
Message-ID: <7vslb6mnva.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704111605210.6730@woody.linux-foundation.org>

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

Show 12 quoted lines

> 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.

> 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.