On Tue, Oct 16, 2018 at 4:13 PM Jonathan Tan <jonathanta...@google.com> wrote: > > > Thanks for the review of the whole series! > > > > I have redone this series, addressing all your comments. I addressed > > this comment differently than suggested, and put the submodule > > repository argument at the end of the parameter list, such that it > > goes with all the other arguments to be filled in. > > Sounds good.
Actually I changed my mind on that after figuring out how to free the submodule repository appropriately and went with your original suggestion. > > > I was about to resend the series, but test-merged with the other > > submodule series in flight > > (origin/sb/submodule-recursive-fetch-gets-the-tip) > > which had some conflicts that I can easily resolve by rebasing on top. > > I presume you are talking about [1]? Maybe consider rebasing that one on > top of this instead, since this is just a refactoring whereas > submodule-recursive-fetch-gets-the-tip changes functionality, from what > I understand of patches 8 and 9. >From my understanding, that series is further along than this one, so I would not want to mix up their order. Currently I am rebasing this on top of select topics from next, (ds/reachable) as that are the other conflicts that I'd have to deal with. > [1] https://public-inbox.org/git/20181016181327.107186-1-sbel...@google.com/ > > > It conflicts a lot when merging to next, due to the latest patch > > ("Apply semantic patches from previous patches"), so I am not sure > > how to proceed properly. Maybe we'd omit that patch and > > run 'make coccicheck' on next to apply the semantic patches > > there instead. > > Omitting the patch sounds good to me. For me, just stating that you have > excluded any coccinelle-generated patches in order to ease merging into > the various branches is sufficient, and people can test the coccinelle > patches included by running "make coccicheck" then "patch -p1 > <contrib/coccinelle/the_repository.cocci.patch". ok. Thanks, Stefan
