git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Jeff King <peff@peff.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	PJ Hyett <pjhyett@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: Bad objects error since upgrading GitHub servers to 1.6.1
Date: Wed, 28 Jan 2009 10:26:51 -0800	[thread overview]
Message-ID: <7vmydbs2vo.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20090128161652.GK1321@spearce.org

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Actually, the only time where it *isn't* a corruption is when its
> input to "git bundle create A.bdl ... -not $SOMEBADID" as that is
> the exact same thing as coming from the other side via send-pack.

And notice that it is about a nagative ref.

Another case you may use an object ID that may or may not be good and it
is not a corruption is when a Porcelain has an object ID obtained from
somewhere, and wants to know if it is safe to use the object.  After
determining that the object itself exists (e.g. via "cat-file -t"),
you run

	rev-list --objects $THAT_UNKNOWN_ID --not --all

to see if it is reachable from some of your own refs, or at least it is
connected to them without gaps.  If it errors out while traversing, you
know it is bad; if it doesn't, you know you can merge one of the commits
reachable from your refs with it and put the result in your ref without
violating the ref-objects contract.

Notice that in this case, it is about a positive ref, and revision
machinery is set to notice the breakage.

So in that sense, the existing semantics is internally consistent.  The
rules (I am not making up a new rule here, but just spelling out) are:

 (1) You cannot just pick a random object that happens to exist in your
     repository, traverse to the objects it refers to and expect
     everything exists;

 (2) If an object is reachable from any of your refs, however, you can
     expect everything reachable from that object exists.  Otherwise you
     have a corrupt repository [*1*]).

 (3) Your object store may have garbage objects that are not reachable
     from any of your refs and it is normal.

 (4) You can use random objects that may not be well connected as negative
     revs to limit the range of revs (and optionally objects reachable
     from them) listed by object traversal.  If they are well connected,
     they will affect the outcome, but it is not an error if they are
     leftover cruft that is not connected to the positive ones you start
     your listing traversal at.


[Footnote]

*1* You don't have to bring up grafts and shallow.  People who know about
them know they are ways to hide or deliberately introduce this type of
corruption while keeping the system (mostly) working.

  parent reply	other threads:[~2009-01-28 18:28 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-27 23:04 Bad objects error since upgrading GitHub servers to 1.6.1 PJ Hyett
2009-01-27 23:10 ` PJ Hyett
2009-01-27 23:37   ` Johannes Schindelin
2009-01-27 23:39     ` Shawn O. Pearce
2009-01-27 23:51       ` Junio C Hamano
2009-01-28  0:15         ` PJ Hyett
2009-01-28  0:34         ` PJ Hyett
2009-01-28  1:06           ` Junio C Hamano
2009-01-28  1:32             ` Junio C Hamano
2009-01-28  1:38               ` [PATCH] send-pack: Filter unknown commits from alternates of the remote Björn Steinbrink
2009-01-28  1:47                 ` Junio C Hamano
2009-01-28  3:33                 ` Junio C Hamano
2009-01-28  3:58                   ` Björn Steinbrink
2009-01-28  4:13                     ` Junio C Hamano
2009-01-28  4:32                     ` Junio C Hamano
2009-01-28  1:44               ` Bad objects error since upgrading GitHub servers to 1.6.1 Junio C Hamano
2009-01-28  1:57                 ` PJ Hyett
2009-01-28  2:02                   ` Shawn O. Pearce
2009-01-28  3:09                     ` Junio C Hamano
2009-01-28  3:30                       ` Shawn O. Pearce
2009-01-28  3:52                         ` Stephen Bannasch
2009-01-28  3:57                           ` Shawn O. Pearce
2009-01-28  5:44                           ` Junio C Hamano
2009-01-28  4:38                         ` Junio C Hamano
2009-01-28  4:41                           ` Shawn O. Pearce
2009-01-28  7:14                             ` Junio C Hamano
2009-01-28  7:41                               ` Junio C Hamano
2009-01-28  7:51                                 ` [PATCH 1/2] send-pack: do not send unknown object name from ".have" to pack-objects Junio C Hamano
2009-01-28 15:45                                 ` Bad objects error since upgrading GitHub servers to 1.6.1 Linus Torvalds
2009-01-28 19:00                                   ` Junio C Hamano
2009-01-28  7:55                               ` Jeff King
2009-01-28  8:05                                 ` Junio C Hamano
2009-01-28  8:17                                   ` Jeff King
2009-01-28 16:16                                     ` Shawn O. Pearce
2009-01-28 18:16                                       ` Jeff King
2009-01-28 18:26                                       ` Junio C Hamano [this message]
2009-01-28  8:22                                   ` Junio C Hamano
2009-01-28  9:24                                     ` Jeff King
2009-01-28 16:09                               ` Shawn O. Pearce
2009-01-28 16:38                                 ` Nicolas Pitre
2009-01-28 18:11                                 ` Jeff King
2009-01-28  1:00   ` Linus Torvalds
2009-01-28  1:15     ` Björn Steinbrink

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=7vmydbs2vo.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=pjhyett@gmail.com \
    --cc=spearce@spearce.org \
    --cc=torvalds@linux-foundation.org \
    /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).