Re: [PATCHv9 0/6] Expose submodule parallelism to the user

On Thu, Feb 11, 2016 at 12:23 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Stefan Beller [off-list ref] writes:

quoted

quoted

quoted

* This seems to clash with 00/20] refs backend.

quoted

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.