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@xxxxxxxxxxxxx>
---
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
