Before this patch, clear_commit_marks() recursed for each parent. This
could be potentially very expensive in terms of stack space. Probably
the only reason that this did not lead to problems is the fact that we
typically call clear_commit_marks() after marking a relatively small set
of commits.
Use (sort of) a tail recursion instead: first recurse on the parents
other than the first one, and then continue the loop with the first
parent.
Noticed by Shawn Pearce.
Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
---
commit.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/commit.c b/commit.c
index 20fb220..ac24266 100644
--- a/commit.c
+++ b/commit.c
@@ -441,17 +441,22 @@ struct commit *pop_most_recent_commit(struct commit_list **list,
void clear_commit_marks(struct commit *commit, unsigned int mark)
{
- struct commit_list *parents;
+ while (commit) {
+ struct commit_list *parents;
- commit->object.flags &= ~mark;
- parents = commit->parents;
- while (parents) {
- struct commit *parent = parents->item;
+ if (!(mark & commit->object.flags))
+ return;
- /* Have we already cleared this? */
- if (mark & parent->object.flags)
- clear_commit_marks(parent, mark);
- parents = parents->next;
+ commit->object.flags &= ~mark;
+
+ parents = commit->parents;
+ if (!parents)
+ return;
+
+ while ((parents = parents->next))
+ clear_commit_marks(parents->item, mark);
+
+ commit = commit->parents->item;
}
}
--
1.5.3.4.1169.g5fb8d
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
