git/list[1] front-page[2] threads[3] people[4] search[5] about
 

revision: propagate flag bits from tags to pointees

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 15, 2014, 20:26 UTC
Message-ID
<xmqqwqi10z6i.fsf_-_@gitster.dls.corp.google.com>
In-Reply-To
<xmqq1u092f2k.fsf@gitster.dls.corp.google.com>

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 <gitster@pobox.com>
---
 * Comes directly on top of the faulty commit, so that we could
   backport it to 1.8.4.x series.
 revision.c               |  2 +-
 t/t6000-rev-list-misc.sh | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 7010aff..6d1c8f9 100644
--- a/revision.c
+++ b/revision.c
@@ -265,6 +265,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;
 	}
 
 	/*
@@ -276,7 +277,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;
 		}
diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
index 15e3d64..b84d6b0 100755
--- a/t/t6000-rev-list-misc.sh
+++ b/t/t6000-rev-list-misc.sh
@@ -56,4 +56,15 @@ test_expect_success 'rev-list A..B and rev-list ^A B are the same' '
 	test_cmp expect actual
 '
 
+test_expect_success 'symleft flag bit is propagated down from tag' '
+	git log --format="%m %s" --left-right v1.0...master >actual &&
+	cat >expect <<-\EOF &&
+	> two
+	> one
+	< another
+	< that
+	EOF
+	test_cmp expect actual
+'
+
 test_done
Previous: Junio C HamanoNext: Jeff King
Message 5 of 9 in “git-log --cherry-pick gives different results when using tag or tag^{}”
  1. Francis MoreauJan 10, 2014
  2. Jeff KingJan 15, 2014
  3. Francis MoreauJan 15, 2014
  4. Junio C HamanoJan 15, 2014
  5. revision: propagate flag bits from tags to pointeesJunio C Hamano, Jan 15, 2014
  6. Jeff KingJan 15, 2014
  7. Junio C HamanoJan 15, 2014
  8. Junio C HamanoJan 15, 2014
  9. Jeff KingJan 15, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.