From 2ac5e4470b7a17303b10ba539d8aa84e870bade9 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 15 Jan 2014 15:38:01 -0800 Subject: revision: mark contents of an uninteresting tree uninteresting "git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a list of objects inside B's tree, but please exclude the objects that appear inside A's tree". we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in the above example) and call mark_tree_uninteresting() on it; this unfortunately prevents us from recursing into the tree and marking the objects in the tree as uninteresting. The reason why "git log ^A A" yields an empty set of commits, i.e. we do not have a similar issue for commits, is because we call mark_parents_uninteresting() after seeing an uninteresting commit. The uninteresting-ness of the commit itself does not prevent its parents from being marked as uninteresting. Introduce mark_tree_contents_uninteresting() and structure the code in handle_commit() in such a way that it makes it the responsibility of the callchain leading to this function to mark commits, trees and blobs as uninteresting, and also make it the responsibility of the helpers called from this function to mark objects that are reachable from them. Note that this is a very old bug that probably dates back to the day when "rev-list --objects" was introduced. The line to clear tree->object.parsed at the end of mark_tree_contents_uninteresting() can be removed when this fix is merged to the codebase after 6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05). Signed-off-by: Junio C Hamano --- revision.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) (limited to 'revision.c') diff --git a/revision.c b/revision.c index 7010aff817..28449c5140 100644 --- a/revision.c +++ b/revision.c @@ -98,17 +98,12 @@ static void mark_blob_uninteresting(struct blob *blob) blob->object.flags |= UNINTERESTING; } -void mark_tree_uninteresting(struct tree *tree) +static void mark_tree_contents_uninteresting(struct tree *tree) { struct tree_desc desc; struct name_entry entry; struct object *obj = &tree->object; - if (!tree) - return; - if (obj->flags & UNINTERESTING) - return; - obj->flags |= UNINTERESTING; if (!has_sha1_file(obj->sha1)) return; if (parse_tree(tree) < 0) @@ -135,6 +130,19 @@ void mark_tree_uninteresting(struct tree *tree) */ free(tree->buffer); tree->buffer = NULL; + tree->object.parsed = 0; +} + +void mark_tree_uninteresting(struct tree *tree) +{ + struct object *obj = &tree->object; + + if (!tree) + return; + if (obj->flags & UNINTERESTING) + return; + obj->flags |= UNINTERESTING; + mark_tree_contents_uninteresting(tree); } void mark_parents_uninteresting(struct commit *commit) @@ -294,7 +302,8 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object if (!revs->tree_objects) return NULL; if (flags & UNINTERESTING) { - mark_tree_uninteresting(tree); + tree->object.flags |= UNINTERESTING; + mark_tree_contents_uninteresting(tree); return NULL; } add_pending_object(revs, object, ""); @@ -309,7 +318,7 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object if (!revs->blob_objects) return NULL; if (flags & UNINTERESTING) { - mark_blob_uninteresting(blob); + blob->object.flags |= UNINTERESTING; return NULL; } add_pending_object(revs, object, ""); -- cgit v1.2.1 From a74352867e689d50ee9c368f24d4a64392e27a35 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 15 Jan 2014 12:26:13 -0800 Subject: revision: propagate flag bits from tags to pointees With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the "git log" family of commands no longer directly places the object pointed by the tag in the pending object array when it sees a tag object. We used to place pointee there after copying the flag bits like UNINTERESTING and SYMMETRIC_LEFT. This change meant that any flag that is relevant to later history traversal must now be propagated to the pointed objects (most often these are commits) while starting the traversal, which is partly done by handle_commit() that is called from prepare_revision_walk(). We did propagate UNINTERESTING, but did not do so for others, most notably SYMMETRIC_LEFT. This caused "git log --left-right v1.0..." (where "v1.0" is a tag) to start losing the "leftness" from the commit the tag points at. Signed-off-by: Junio C Hamano --- revision.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'revision.c') diff --git a/revision.c b/revision.c index 28449c5140..aec03332ca 100644 --- a/revision.c +++ b/revision.c @@ -273,6 +273,7 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object return NULL; die("bad object %s", sha1_to_hex(tag->tagged->sha1)); } + object->flags |= flags; } /* @@ -284,7 +285,6 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object if (parse_commit(commit) < 0) die("unable to parse commit %s", name); if (flags & UNINTERESTING) { - commit->object.flags |= UNINTERESTING; mark_parents_uninteresting(commit); revs->limited = 1; } @@ -302,7 +302,6 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object if (!revs->tree_objects) return NULL; if (flags & UNINTERESTING) { - tree->object.flags |= UNINTERESTING; mark_tree_contents_uninteresting(tree); return NULL; } @@ -314,13 +313,10 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object * Blob object? You know the drill by now.. */ if (object->type == OBJ_BLOB) { - struct blob *blob = (struct blob *)object; if (!revs->blob_objects) return NULL; - if (flags & UNINTERESTING) { - blob->object.flags |= UNINTERESTING; + if (flags & UNINTERESTING) return NULL; - } add_pending_object(revs, object, ""); return NULL; } -- cgit v1.2.1