I mentioned previously [1] the possibility of not running maintenance steps (commit graph writing and "git maintenance") if no packs were fetched, but looking at things again, I think that we shouldn't do that - in particular, if I ran "git fetch --refetch", I would fully expect the objects to be repacked, even if Git wasn't able to detect conclusively whether a pack was transmitted. So I went back to my original idea of detecting when an object is missing. In trying to balance the concerns of both doing something as reasonable as possible in such a repo corruption case, and not slowing down and/or unnecessarily complicating the main code flow, I decided to detect when an object is present in the commit graph but not in the object DB, and to limit this detection for objects specified in the fetch refspec. Upon detection, we can't fix it due to reasons mentioned in the commit message, so I decided to print a warning. An alternate option is to make it a fatal error (instead of a warning) if an object is detected to be in the commit graph but not the object DB. I haven't thought through the ramifications of that, though. [1] https://lore.kernel.org/git/20241028225504.4151804-1-jonathantanmy@xxxxxxxxxx/ Jonathan Tan (2): Revert "fetch-pack: add a deref_without_lazy_fetch_extended()" fetch-pack: warn if in commit graph but not obj db fetch-pack.c | 45 +++++++++++++++++++++++++-------------------- object.h | 2 +- 2 files changed, 26 insertions(+), 21 deletions(-) -- 2.47.0.163.g1226f6d8fa-goog
