Browse Source

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>
maint
Junio C Hamano 16 years ago
parent
commit
aeeae1b771
  1. 10
      revision.c
  2. 37
      t/t5519-push-alternates.sh

10
revision.c

@ -183,8 +183,11 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object @@ -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));
}
}

/*
@ -479,9 +482,10 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, @@ -479,9 +482,10 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
while (parent) {
struct commit *p = parent->item;
parent = parent->next;
if (p)
p->object.flags |= UNINTERESTING;
if (parse_commit(p) < 0)
return -1;
p->object.flags |= UNINTERESTING;
continue;
if (p->parents)
mark_parents_uninteresting(p);
if (p->object.flags & SEEN)

37
t/t5519-push-alternates.sh

@ -103,4 +103,41 @@ test_expect_success 'bob works and pushes' ' @@ -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

Loading…
Cancel
Save