Jeff King <p...@peff.net> writes:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
