On Wed, Jan 15, 2014 at 12:26:13PM -0800, Junio C Hamano wrote:

> 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
> 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 <gits...@pobox.com>
> ---

Looks good to me. As per my previous mail, I _think_ you could squash

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.

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

Reply via email to