{"thread":{"id":"63540","subject":"[RFC] revision.c: traverse to many revisions to find boundary","startedAt":"2025-05-28T16:37:00Z","lastAt":"2025-05-28T16:37:00Z","messageCount":1,"participants":["lidongyan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"519083","messageId":"3378F2BB-B2FB-4E07-9C02-A57D43D1A89C@smail.nju.edu.cn","threadId":"63540","inReplyTo":null,"subject":"[RFC] revision.c: traverse to many revisions to find boundary","fromName":"lidongyan","fromEmail":"502024330056@smail.nju.edu.cn","sentAt":"2025-05-28T16:36:38Z","receivedAt":"2025-05-28T16:37:00Z","isPatch":false,"sender":{"key":"502024330056@smail.nju.edu.cn","avatar":"https://avatars.githubusercontent.com/u/77328395?v=4"},"body":"In revisions.c:get_revision_internal(), when the caller wants to\nretrieve all boundary commits, this function identifies the parents\nof the last commits emitted by get_revision_1() as boundary commits.\nHowever, if get_revision_1() encounters an UNINTERESTING commit,\nit continues to recursively traverse the parents of that commit. \nBut only the earliest UNINTERESTING commits are eventually marked\n as boundary.\n\nThis raises the question: when revs->boundary is true, do we really need\nto continue traversing after encountering an UNINTERESTING commit?\nPerhaps we could optimize this by stopping the traversal earlier—for example,\nby doing something like this:\n\ndiff --git a/revision.c b/revision.c\nindex 2c36a9c179..0d99c22913 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1176,6 +1176,8 @@ static int process_parents(struct rev_info *revs, struct commit *commit,\n \t\t\tif (p->object.flags & SEEN)\n \t\t\t\tcontinue;\n \t\t\tp->object.flags |= (SEEN | NOT_USER_GIVEN);\n+\t\t\tif (revs->boundary)\n+\t\t\t\tbreak;\n \t\t\tif (list)\n \t\t\t\tcommit_list_insert_by_date(p, list);\n \t\t\tif (queue)"}]}