Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html