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

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

But when you fsck the subproject repository in isolation in the
earlier step in your procedure, that is not taken into account,
is it?

The situation I had in mind was not about pruning, but an
earlier fetch, either the native one that unpacks the objects
into loose form or a http walker, fetched a commit near the tip
but was interrupted/killed before finishing the fetch nor
updating the ref.  The tip of such an incomplete commit chain
would be reported dangling.  They are ahead of your refs but
they may lack commits and trees to complete the chain back to
your refs yet.  When the higher-level project points at such a
commit, the existence of the commit is not a proof that
everything needed to complete the commit is available.

We need to prove that separately, and that was my suggestion to
run a "rev-list --objects $those-commits --not --all" in the
subproject repository, simlar to what the quick-fetch topic
does.



-
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