From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: "Stefan Näwe" <stefan.naewe@atlas-elektronik.com>
Subject: [RFC/PATCH 0/3] silence missing-link warnings in some cases
Date: Mon, 1 Jun 2015 05:54:10 -0400 [thread overview]
Message-ID: <20150601095410.GA16976@peff.net> (raw)
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
next prev parent reply other threads:[~2015-06-01 9:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 7:37 git gc gives "error: Could not read..." Stefan Näwe
2015-06-01 8:14 ` Jeff King
2015-06-01 8:40 ` Stefan Näwe
2015-06-01 8:52 ` Jeff King
2015-06-01 9:14 ` Stefan Näwe
2015-06-01 9:58 ` Jeff King
2015-06-01 10:08 ` Stefan Näwe
2015-06-01 10:22 ` Jeff King
2015-06-01 9:54 ` Jeff King [this message]
2015-06-01 9:56 ` [PATCH 1/3] add quieter versions of parse_{tree,commit} Jeff King
2015-06-01 9:56 ` [PATCH 2/3] silence broken link warnings with revs->ignore_missing_links Jeff King
2015-06-01 9:56 ` [PATCH 3/3] suppress errors on missing UNINTERESTING links Jeff King
2015-06-01 15:03 ` [RFC/PATCH 0/3] silence missing-link warnings in some cases Junio C Hamano
2015-06-01 15:41 ` Jeff King
2015-06-01 16:11 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150601095410.GA16976@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=stefan.naewe@atlas-elektronik.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).