mirror of
https://github.com/git/git
synced 2024-08-27 11:39:22 +00:00
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>
This commit is contained in:
parent
02322e1619
commit
aeeae1b771
10
revision.c
10
revision.c
|
@ -183,9 +183,12 @@ 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));
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* Commit object? Just return it, we'll do all the complex
|
||||
|
@ -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 (parse_commit(p) < 0)
|
||||
return -1;
|
||||
if (p)
|
||||
p->object.flags |= UNINTERESTING;
|
||||
if (parse_commit(p) < 0)
|
||||
continue;
|
||||
if (p->parents)
|
||||
mark_parents_uninteresting(p);
|
||||
if (p->object.flags & SEEN)
|
||||
|
|
|
@ -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…
Reference in a new issue