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.
