{"thread":{"id":"60342","subject":"[PATCH] revision: Don't queue uninteresting commits","startedAt":"2023-10-11T12:36:10Z","lastAt":"2023-11-06T11:29:15Z","messageCount":3,"participants":["Øystein Walle","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"483044","messageId":"20231011123534.119994-1-oystwa@gmail.com","threadId":"60342","inReplyTo":null,"subject":"[PATCH] revision: Don't queue uninteresting commits","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2023-10-11T12:35:34Z","receivedAt":"2023-10-11T12:36:10Z","isPatch":true,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Currently all given commits are added to the topo_queue during\ninit_topo_walk(). Later on in get_revision_1() the uninteresting ones\nare skipped because simplify_commit() tells it to.\n\nLet's not add them to the topo_queue in the first place.\n\nSigned-off-by: Øystein Walle <oystwa@gmail.com>\n---\n\nI noticed this while trying to understand the generation based algorithm\nintroduced in b45424181e (revision.c: generation-based topo-order\nalgorithm, 2018-11-01) in an attempt to write a similar one for\ngitoxide. Comparing my solution to git's output I fixed a mismatch by\nessentially doing this, and it turns out it works in git too. I am not\nextremely confident, but all the tests pass...\n\nFor fun I also tried removing the UNINTERESTING check from\nget_commit_action() altogether but then a lot of tests fail. I expected\nthat because both the flag and function predate the new algorithm.\n\n revision.c | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/revision.c b/revision.c\nindex 2f4c53ea20..deeab813c7 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -3681,7 +3681,8 @@ static void init_topo_walk(struct rev_info *revs)\n \tfor (list = revs->commits; list; list = list->next) {\n \t\tstruct commit *c = list->item;\n \n-\t\tif (*(indegree_slab_at(&info->indegree, c)) == 1)\n+\t\tif (*(indegree_slab_at(&info->indegree, c)) == 1 &&\n+\t\t    !(c->object.flags & UNINTERESTING))\n \t\t\tprio_queue_put(&info->topo_queue, c);\n \t}\n \n-- \n2.34.1\n\n"},{"id":"483057","messageId":"xmqqpm1lnme4.fsf@gitster.g","threadId":"60342","inReplyTo":"20231011123534.119994-1-oystwa@gmail.com","subject":"Re: [PATCH] revision: Don't queue uninteresting commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-11T16:40:03Z","receivedAt":"2023-10-11T16:40:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle <oystwa@gmail.com> writes:\n\n> Currently all given commits are added to the topo_queue during\n> init_topo_walk(). Later on in get_revision_1() the uninteresting ones\n> are skipped because simplify_commit() tells it to.\n>\n> Let's not add them to the topo_queue in the first place.\n\nWhat is not described here is what benefit we are expecting to gain\nby making this change.  Is anything leaking?  Are we showing wrong\noutput?  Is the effect something we can demonstrate, and more\nimportantly we can protect from future breakages, with a test or\ntwo?\n\n"},{"id":"484459","messageId":"CAFaJEqtN0b+Prv79E2=sODaw8vRVGD-Ane7U+WzoFoTWkvCNkA@mail.gmail.com","threadId":"60342","inReplyTo":"xmqqpm1lnme4.fsf@gitster.g","subject":"Re: [PATCH] revision: Don't queue uninteresting commits","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2023-11-06T11:28:36Z","receivedAt":"2023-11-06T11:29:15Z","isPatch":true,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Hi, Junio, and sorry for the late response.\n\nOn Wed, 11 Oct 2023 at 18:40, Junio C Hamano <gitster@pobox.com> wrote:\n\n> What is not described here is what benefit we are expecting to gain\n> by making this change.  Is anything leaking?  Are we showing wrong\n> output?  Is the effect something we can demonstrate, and more\n> importantly we can protect from future breakages, with a test or\n> two?\n\nAs far as I know there is no significant benefit to this change. The\nonly one I can think of is a case such as this:\n\n    git rev-list some-rev ^a ^very ^large ^amount ^of ^negative ^revs ^here\n\nbut even then I would assume the work done by the algorithm in total is\nso large that the work saved by this change is insignificant.\n\nI was just a bit happy after grokking a piece of this code and let the\nexcitement get the best of me :-) I suggest we just drop it.\n\nØsse\n"}]}