Re: revision: propagate flag bits from tags to pointees
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:40
Jeff King [off-list ref] writes:
quoted hunk
Looks good to me. As per my previous mail, I _think_ you could squash in:diff --git a/revision.c b/revision.c index f786b51..2db906c 100644 --- a/revision.c +++ b/revision.c@@ -316,13 +316,10 @@ static struct commit *handle_commit(struct rev_info *revs, * 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) { - mark_blob_uninteresting(blob); + if (flags & UNINTERESTING) return NULL; - } add_pending_object(revs, object, ""); return NULL; }but that is not very much code reduction (and mark_blob_uninteresting is very cheap). So it may not be worth the risk that my analysis is wrong. :)
Your analysis is correct, but I think the pros-and-cons of the your squashable change boils down to the choice between: - leaving it in will keep similarity between tree and blob codepaths (both have mark_X_uninteresting(); and - reducing cycles by taking advantage of the explicit knowledge that mark_X_uninteresting() recurses for a tree while it does not for a blob. But I have a suspicion that my patch may break if any codepath looks at the current flag on the object and decides "ah, it already is marked" and punts. It indeed looks like mark_tree_uninteresting() does have that property. When an uninteresting tag directly points at a tree, if we propagate the UNINTERESTING bit to the pointee while peeling, wouldn't we end up calling mark_tree_uninteresting() on a tree, whose flags already have UNINTERESTING bit set, causing it not to recurse?