Derrick Stolee <[email protected]> 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.
