Subject: [RFC/PATCH 0/3] silence missing-link warnings in some cases

From: Jeff King <[email-masked]>
Date: Mon, 1 Jun 2015 05:54:10 -0400

Stefan noticed that running "git gc" with a recent version of git causes
some useless complaints about missing objects.

The reason is that since git d3038d2 (prune: keep objects reachable from
recent objects, 2014-10-15), we will traverse objects that are not
reachable but have recent mtimes (within the 2-week prune expiration
window). Because they are not reachable, we may not actually have all of
their ancestors; we use the revs->ignore_missing_links option to avoid
making this a fatal error. But we still print an error message. This
series suppresses those messages.

The first two patches below implement that. The third one gives the same
treatment to UNINTERESTING parents, which we implicitly ignore when they
are missing. I have slightly mixed feelings on this, just because it
could be a clue that there is repo corruption. E.g., if you do:

  git log foo..bar

and we find that "foo^" is missing, it is the only error message you
get. OTOH, I think the reason we ignore errors with UNINTERESTING
parents is that it does not necessarily mean corruption. E.g., while
serving a fetch, if the client claims to have "x", we check only
"has_sha1_file(x)" before putting the object on the UNINTERESTING side
of our traversal. It might not be reachable at all, but rather just part
of an incomplete segment of unreachable history. Of course, with modern
git (post-d3038d2), we try to avoid getting that situation in the first
place, which means that it _is_ an exceptional situation, and we should
continue to at least print the error message.

Note that post-d3038d2, it is also exceptional to see this in the
ignore_missing_link cases, too. The reason Stefan is seeing it is
probably that the repo was pruned in the past 2 weeks by an older
version of git (so it removed an older "x^", but kept "x"; whereas
modern git would keep both). So yet another possibility is to scrap this
whole series. Within 2 weeks the problem will magically go away on its
own, or sooner if the user runs "git prune".

  [1/3]: add quieter versions of parse_{tree,commit}
  [2/3]: silence broken link warnings with revs->ignore_missing_links
  [3/3]: suppress errors on missing UNINTERESTING links

-Peff