[PATCH 2/2] revision: keep topo-walk free of unintersting commits

From: Derrick Stolee <stolee@gmail.com>
To: git@vger.kernel.org
Cc: jnareb@gmail.com, jrnieder@google.com, szeder.dev@gmail.com,
	mh@glandium.org, Derrick Stolee <dstolee@microsoft.com>
Subject: [PATCH 2/2] revision: keep topo-walk free of unintersting commits
Date: Tue, 21 May 2019 09:59:53 -0400	[thread overview]
Message-ID: <20190521135953.214701-1-dstolee@microsoft.com> (raw)
In-Reply-To: <20190521131438.58394-1-dstolee@microsoft.com>

When updating the topo-order walk in b454241 (revision.c: generation-based
topo-order algorithm, 2018-11-01), the logic was a huge rewrite of the
walk logic. In that massive change, we accidentally included the
UNINTERESTING commits in expand_topo_walk(). This means that a simple
query like

    git rev-list --topo-order HEAD~1..HEAD

will expand the topo walk for all commits reachable from HEAD, and not
just one commit.

This change should speed up these cases, but there is still a need
for corrected commit-date for some A..B queries.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---

Sorry for the patch-spam, but I took a moment to check this command
on the Git repo, and was able to reproduce the slowness. That didn't
make sense to me, so I added some log messages to expand_topo_walk()
and notices we were walking the UNINITERESTING commits. This is part
of the reason the new logic is slower for A..B commands, but not the
whole reason.

You'll want this patch as well for a test.

Thanks,
-Stolee

 revision.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/revision.c b/revision.c
index be6ccf5786..621feb9df7 100644
--- a/revision.c
+++ b/revision.c
@@ -3265,6 +3265,9 @@ static void expand_topo_walk(struct rev_info *revs, struct commit *commit)
 		struct commit *parent = p->item;
 		int *pi;
 
+		if (parent->object.flags & UNINTERESTING)
+			continue;
+
 		if (parse_commit_gently(parent, 1) < 0)
 			continue;
 
-- 
2.22.0.rc1

