On Thu, Feb 11, 2016 at 12:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Stefan Beller <sbeller@xxxxxxxxxx> writes: >> >>>>> * This seems to clash with 00/20] refs backend. >>>>>> Applied this on top of a merge between the current 'master' and >>>>>> 'sb/submodule-parallel-update' topic to untangle the dependency; >>>>>> otherwise there is no way for this topic to make progress X-<. >>>>> >>>>> Anything I can do to help with easing the clash? >>>> >>>> Perhaps try to rebase the series on top of such a merge (with this >>>> updated series) yourself and propose it as a basis for the next >>>> reroll for David? In short, working together with topic(s) that >>>> touch the same area? >>> >>> Ok, I'll see if I can find a better commit to base this series on. >> >> That is not what I meant. I meant rebasing the refs-backend series >> on top of a merge between this one and 'master', just like the way I >> queued the refs-backend series on top of a merge between the >> previous round of this series and 'master'. >> >> These two topics want to update the same piece of code, so another >> possibility is to rebase this series on top of a merge between >> refs-backend and 'master', but the current iteration of refs-backend >> already depends on the previous round of this topic. Rebasing this >> on top of refs-backend would involve first adjusting parts of >> refs-backend that touched the same code as the previous round of >> submodule-parallel-update touched so that refs-backend would work >> directly on top of 'master', and then including the necessary change >> to the refs-backend code while rebuilding submodule-parallel-update >> on top of the result. So I do not think you would go in that >> direction. > > Having said that, at least for this round, I do not think there is > nothing to do at this point on your end; I just created a merge > between master and your updated sb/submodule-parallel-update and > then rebased the LMDB series on top of it. It at least applies > cleanly and I expect it would test OK as well (the test is still > running). I was about to send another round of this series with all the discussion addressed and then take a look how to resolve any conflicts if any. This sounds promising. > > On your plate is to adjust the submodule-init topic so that it knows > that the .update field no longer is a string (but is now an enum). After the reroll of this series. > > I did try doing that myself to see the extent of necessary changes > but did not finish it myself, because I suspect that > sb/submodule-parallel-update may need further updates. I would hope to address that all within the next round, as the review discussion seemed to have died down and I'll be fixing all the issues pointed at. Thanks, Stefan > > Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html