git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jun 1, 2015, 09:54 UTC
Message-ID
<20150601095410.GA16976@peff.net>
In-Reply-To
<20150601085226.GA20537@peff.net>

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
Previous: Jeff KingNext: Jeff King
Message 9 of 15 in “git gc gives "error: Could not read..."”
  1. Stefan NäweJun 1, 2015
  2. Jeff KingJun 1, 2015
  3. Stefan NäweJun 1, 2015
  4. Jeff KingJun 1, 2015
  5. Stefan NäweJun 1, 2015
  6. Jeff KingJun 1, 2015
  7. Stefan NäweJun 1, 2015
  8. Jeff KingJun 1, 2015
  9. 0/3 silence missing-link warnings in some casesJeff King, Jun 1, 2015
  10. 1/3 add quieter versions of parse_{tree,commit}Jeff King, Jun 1, 2015
  11. 2/3 silence broken link warnings with revs->ignore_missing_linksJeff King, Jun 1, 2015
  12. 3/3 suppress errors on missing UNINTERESTING linksJeff King, Jun 1, 2015
  13. Junio C HamanoJun 1, 2015
  14. Jeff KingJun 1, 2015
  15. Junio C HamanoJun 1, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.