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: 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: Tue, 27 Jan 2009 23:41:22 -0800	[thread overview]
Message-ID: <7vvdrzvpwd.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7vd4e7x5ov.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 27 Jan 2009 23:14:56 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Here is my work in progress.  It introduces "ignore-missing-negative"
> option to the revision traversal machinery, and squelches the places we
> currently complain loudly and die when we expect an object to be
> available, when the color we are going to paint the object with is
> UNINTERESTING.
>
> I have a mild suspicion that it may even be the right thing to ignore them
> unconditionally, and it might even match the intention of Linus's original
> code.  That would make many hunks in this patch much simpler.
>
> The evidences behind this suspicion are found in a handful of places in
> revision.c.  mark_blob_uninteresting() does not complain if the caller
> fails to find the blob.  mark_tree_uninteresting() does not, either.
> mark_parents_uninteresting() does not, either, and it even has a comment
> that strongly suggests the original intention was not to care about
> missing UNINTERESTING objects.

Here is what I ended up with doing.  It lost "ignore-missing-negative"
so missing UNINTERESTING objects are non-error events more uniformly,
but on the other hand get_reference() which is about the command line
arguments always wants the named objects to exist, even if they are
marked as UNINTERESTING.

I'll send [PATCH 1/2] which is an update to my previous fix as a follow-up
to this message.

-- >8 --
Subject: [PATCH 2/2] revision traversal: allow UNINTERESTING objects to be missing

Most of the existing codepaths were meant to treat missing uninteresting
objects to be a silently ignored non-error, but there were a few places
in handle_commit() and add_parents_to_list(), which are two key functions
in the revision traversal machinery, that cared:

 - When a tag refers to an object that we do not have, we barfed.  We
   ignore such a tag if it is painted as UNINTERESTING with this change.

 - When digging deeper into the ancestry chain of a commit that is already
   painted as UNINTERESTING, in order to paint its parents UNINTERESTING,
   we barfed if parse_parent() for a parent commit object failed.  We can
   ignore such a parent commit object.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 revision.c                 |    7 +++++--
 t/t5519-push-alternates.sh |   37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/revision.c b/revision.c
index db60f06..ea8ba0f 100644
--- a/revision.c
+++ b/revision.c
@@ -183,8 +183,11 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
 		if (!tag->tagged)
 			die("bad tag");
 		object = parse_object(tag->tagged->sha1);
-		if (!object)
+		if (!object) {
+			if (flags & UNINTERESTING)
+				return NULL;
 			die("bad object %s", sha1_to_hex(tag->tagged->sha1));
+		}
 	}
 
 	/*
@@ -480,7 +483,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
 			struct commit *p = parent->item;
 			parent = parent->next;
 			if (parse_commit(p) < 0)
-				return -1;
+				continue;
 			p->object.flags |= UNINTERESTING;
 			if (p->parents)
 				mark_parents_uninteresting(p);
diff --git a/t/t5519-push-alternates.sh b/t/t5519-push-alternates.sh
index 6dfc55a..96be523 100755
--- a/t/t5519-push-alternates.sh
+++ b/t/t5519-push-alternates.sh
@@ -103,4 +103,41 @@ test_expect_success 'bob works and pushes' '
 	)
 '
 
+test_expect_success 'alice works and pushes yet again' '
+	(
+		# Alice does not care what Bob does.  She does not
+		# even have to be aware of his existence.  She just
+		# keeps working and pushing
+		cd alice-work &&
+		echo more and more alice >file &&
+		git commit -a -m sixth.1 &&
+		echo more and more alice >>file &&
+		git commit -a -m sixth.2 &&
+		echo more and more alice >>file &&
+		git commit -a -m sixth.3 &&
+		git push ../alice-pub
+	)
+'
+
+test_expect_success 'bob works and pushes again' '
+	(
+		cd alice-pub &&
+		git cat-file commit master >../bob-work/commit
+	)
+	(
+		# This time Bob does not pull from Alice, and
+		# the master branch at her public repository points
+		# at a commit Bob does not fully know about, but
+		# he happens to have the commit object (but not the
+		# necessary tree) in his repository from Alice.
+		# This should not prevent the push by Bob from
+		# succeeding.
+		cd bob-work &&
+		git hash-object -t commit -w commit &&
+		echo even more bob >file &&
+		git commit -a -m seventh &&
+		git push ../bob-pub
+	)
+'
+
 test_done
-- 
1.6.1.1.273.g0e555

  reply	other threads:[~2009-01-28  7:43 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 [this message]
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
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=7vvdrzvpwd.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --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).