On Tue, Aug 06, 2024 at 09:37:33AM +1200, Han Jiang wrote: > What did you do before the bug happened? (Steps to reproduce your issue) > > (repo7 and repo8 should behave similar to repo5 and repo6, i.e. setup > ".git/objects/info/alternates" && copy/get_pack_of objects;) > (repo7 and repo8 shouldn't: forget to copy/get_pack_of objects.) > (The problem only surfaces after "./client/mirror.git/" is removed: > repo7 and repo8 should have the original objects (so git log shouldn't > give error) but they don't have.) I don't think this expectation is correct. Using "--reference" without "-dissociate" creates a dependency on the mirror repository. It's not safe to delete it. This is discussed in the "--shared" description of git-clone(1), and the "--reference" description refers to it. So in your example: > git -C './client' clone --reference='./mirror.git' --no-local '../server/repo.git' './repo7' I would not expect repo7 to have any objects. Its needs were satisfied by the mirror, and when it told the upload-pack process running in server/repo.git what it had, that process knew that it did not need to send any objects. It's actually your repo5 and repo6 that are the oddballs: > git -C './client' clone --reference='./mirror.git' '../server/repo.git' './repo5' Here since we are cloning a local-file repo, we take a shortcut and do not do any object negotiation at all! Instead, we just take all of the objects from server/repo.git as hardlinks, since doing so is less work than figuring out what we might need. It makes us robust to mirror.git being removed (since we ended up with duplicates of all of its objects anyway). But it's still not safe in the long run. If the mirror gets new objects, we'd rely on them for subsequent fetches (rather than getting new copies), and the same dependency is created. -Peff
