Junio C Hamano <gitster@xxxxxxxxx> writes: > Sorry, but I do not think I can relay that as an explanation why it > won't cause problems to a third person. OK, ignore this. I was being stupid. > The entries in shallow file says that history behind them may not > exist in the repository due to its shallowness but history after > them are supposed to be traversable (otherwise we have a repository > corruption). It is true that an entry that itself no longer exists > in this repository should not be in shallow file, as the presence of > that entry breaks that promise the file is making---that commit > ought to exist and it is safe to traverse down to it, so keeping the > entry in the file is absolutely a wrong thing to do. > > But that does not automatically mean that just simply removing it > makes the resulting repository good, does it? Wouldn't the solution > for that corruption be to set a new entry to stop history traversal > before reaching that (now-missing) commit? The above is overly pessimistic and worried about an impossible situation, I would think. The reason why a commit that used to be in the shallow file is being pruned during a "repack" is because it has become unreachable. By definition, no future history traversal that wants to enumerate reachable commits needs to be stopped from finding that commits that are older than this commit being pruned are missing by having this in the shallow list. If there is a ref or a reflog entry from which such a problematic traversal starts at, we wouldn't be pruing this commit in the first place, because the commit has not become unreachable yet. So a repository does not become corrupt by pruning the commit *and* removing it from the shallow file at the same time.
