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

Linus Torvalds [off-list ref] writes:

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.

On Wed, 11 Apr 2007, Junio C Hamano wrote:

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.

The superproject *is* a ref.

You cannot prune the subprojects on their own. That's the *only* real 
special rule about subprojects. Exactly because pruning them on their own 
is not a valid op to do.

It's the same way with an source of "alternate" objects (or a shared 
object directory) - you'd better not prune them, because other projects 
may have refs to them that you don't know about locally. So this isn't 
somethign new to subprojects.

		Linus