{"thread":{"id":"38288","subject":"Question about the revision walking API","startedAt":"2015-01-06T02:02:30Z","lastAt":"2015-01-06T18:30:32Z","messageCount":5,"participants":["Mike Hommey","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254312","messageId":"20150106020230.GA28274@glandium.org","threadId":"38288","inReplyTo":null,"subject":"Question about the revision walking API","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-01-06T02:02:30Z","receivedAt":"2015-01-06T02:02:30Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI would like to know if the revision walking API works as one would\nexpect with a calling sequence like the following:\n\n- init_revisions\n- add_pending_object/setup_revisions\n- prepare_revision_walk\n- get_revision (repeated)\n- reset_revision_walk (I guess)\n- add_pending_object\n- prepare_revision_walk\n- get_revision (repeated)\n\nThat is, do a first revision walk based on a given rev_info, then reuse that\nrev_info with additional commit objects (in my case, I want to add more\nUNINTERESTING commits) and redo a revision walk based on the modified\nrev_info (so, avoid reinitializing a rev_info and filling it from\nscratch again with the additional UNINTERESTING commits).\n\nI guess I could try and see if that works, but I'd rather have an\ninformed answer than to derive my own from the fact my testcase would\nhappen to work by chance.\n\nCheers,\n\nMike\n"},{"id":"254322","messageId":"xmqq4ms4qk91.fsf@gitster.dls.corp.google.com","threadId":"38288","inReplyTo":"20150106020230.GA28274@glandium.org","subject":"Re: Question about the revision walking API","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-06T10:24:58Z","receivedAt":"2015-01-06T10:24:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> I would like to know if the revision walking API works as one would\n> expect with a calling sequence like the following:\n>\n> - init_revisions\n> - add_pending_object/setup_revisions\n> - prepare_revision_walk\n> - get_revision (repeated)\n> - reset_revision_walk (I guess)\n\nAround here you would need to clear flag bits left on the objects by\nyour previous traversal. After \"git log A..B\", commits in that\nrange would have various combinations of SEEN, ADDED and SHOWN\nflags, and also some commits reachable from A would be marked as\nUNINTERESTING. You do not want these to interfere with your next\ntraversal which may not have anything to do with what you computed\nwith the previous round.\n\n> - add_pending_object\n> - prepare_revision_walk\n> - get_revision (repeated)\n"},{"id":"254327","messageId":"20150106105122.GA32170@glandium.org","threadId":"38288","inReplyTo":"xmqq4ms4qk91.fsf@gitster.dls.corp.google.com","subject":"Re: Question about the revision walking API","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-01-06T10:51:22Z","receivedAt":"2015-01-06T10:51:22Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Jan 06, 2015 at 02:24:58AM -0800, Junio C Hamano wrote:\n> Mike Hommey writes:\n> \n> > I would like to know if the revision walking API works as one would\n> > expect with a calling sequence like the following:\n> >\n> > - init_revisions\n> > - add_pending_object/setup_revisions\n> > - prepare_revision_walk\n> > - get_revision (repeated)\n> > - reset_revision_walk (I guess)\n> \n> Around here you would need to clear flag bits left on the objects by\n> your previous traversal. After \"git log A..B\", commits in that\n> range would have various combinations of SEEN, ADDED and SHOWN\n\nafaics, that's what reset_revision_walk does.\n\n> flags, and also some commits reachable from A would be marked as\n> UNINTERESTING.\n\nDo you mean the ancestry of A? That wouldn't matter in my case.\n\n> You do not want these to interfere with your next\n> traversal which may not have anything to do with what you computed\n> with the previous round.\n\nOkay, so aiui, doing a revision walk doesn't impact anything other\nthan the object flags, so I can safely use add_pending_object to add\nto what I already had in the rev_info?\n\nCheers,\n\nMike\n"},{"id":"254334","messageId":"CAP8UFD0mZ4tSF-ZkZh8Z=GdkW4LNQAWuKJYyhyiA4RTGPLX_+g@mail.gmail.com","threadId":"38288","inReplyTo":"20150106020230.GA28274@glandium.org","subject":"Re: Question about the revision walking API","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-01-06T13:37:07Z","receivedAt":"2015-01-06T13:37:07Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\n\nOn Tue, Jan 6, 2015 at 3:02 AM, Mike Hommey wrote:\n> Hi,\n>\n> I would like to know if the revision walking API works as one would\n> expect with a calling sequence like the following:\n>\n> - init_revisions\n> - add_pending_object/setup_revisions\n> - prepare_revision_walk\n> - get_revision (repeated)\n> - reset_revision_walk (I guess)\n> - add_pending_object\n> - prepare_revision_walk\n> - get_revision (repeated)\n>\n> That is, do a first revision walk based on a given rev_info, then reuse that\n> rev_info with additional commit objects (in my case, I want to add more\n> UNINTERESTING commits) and redo a revision walk based on the modified\n> rev_info (so, avoid reinitializing a rev_info and filling it from\n> scratch again with the additional UNINTERESTING commits).\n>\n> I guess I could try and see if that works, but I'd rather have an\n> informed answer than to derive my own from the fact my testcase would\n> happen to work by chance.\n\nI am not sure what you describe above would work, but something like\nwhat is done in bisect.c should work, see check_ancestors() and\nbisect_next_all(). It might not be the most efficient solution though,\nso I am interested if you find something more efficient.\n\nBest,\nChristian.\n"},{"id":"254353","messageId":"xmqqpparpxrr.fsf@gitster.dls.corp.google.com","threadId":"38288","inReplyTo":"CAP8UFD0mZ4tSF-ZkZh8Z=GdkW4LNQAWuKJYyhyiA4RTGPLX_+g@mail.gmail.com","subject":"Re: Question about the revision walking API","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-06T18:30:32Z","receivedAt":"2015-01-06T18:30:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> I am not sure what you describe above would work, but something like\n> what is done in bisect.c should work, see check_ancestors() and\n> bisect_next_all(). It might not be the most efficient solution though,\n> so I am interested if you find something more efficient.\n\nI do not think what bisect does is a correct solution for general\ncase; I didn't check too carefully when I applied your patch long\ntime ago, but I recall that you only clear flag bits from commits\nthat are still in the pending queue in that codepath. That may be\nsufficient if the subsequent traversal goes only outside the area\nprevious traversal walked, but the approach is inappropriate for\ngeneral cases, no?\n"}]}