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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 9, 2016, 22:03 UTC
Message-ID: <xmqqziv91qzi.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYt9bw9MreiBhA_ZQNjS+1Xi71aNGwkjcfC1hwxkOoyYA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 13 quoted lines

>>> * 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.