On 9/25/2018 2:06 PM, Junio C Hamano wrote:
Derrick Stolee <stolee@xxxxxxxxx> writes:
@@ -622,10 +623,7 @@ int can_all_from_reach_with_flag(struct object_array *from,
}
cleanup:
- for (i = 0; i < nr_commits; i++) {
- clear_commit_marks(list[i], RESULT);
- clear_commit_marks(list[i], assign_flag);
- }
+ clear_commit_marks_many(nr_commits, list, RESULT | assign_flag);
free(list);
for (i = 0; i < from->nr; i++)
base-commit: 4067a64672f9db8ca38d5a2682a7cdba7938c18b
This change looks good to me.
This is a tangent, but while re-reading clear_commit_marks() and its
helpers to refresh my memory, I found that the bottom-most helper in
the callchain was written in a very confusing way, but it is not a
fault of this clean-up. I however suspect that it would not help us
all that much to use clear_commit_marks_many() with its current
implementation. It first clears all commits on the first-parent
chain from each list[] element, while accumulating the parent
commits that are yet to be processed in a commit_list in LIFO order,
and then consumes these accumulated side parents the same way. We
probably would benefit by rewriting clear_commit_marks_many() to
traverse from all the tips given in list[] taking advantage of the
generation numbers, using a prio queue to manage the commits
yet-to-be-cleared, or something.
Another commit walk that could be improved by generation numbers? It's
like my bat-signal!
Thanks for pointing me in that direction. I'll take a look.
-Stolee
