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

[Junio C Hamano]

Junio C Hamano  writes:

> Stefan Beller  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).

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

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.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Beller]

On Thu, Feb 11, 2016 at 12:23 PM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>
>> Stefan Beller  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Junio C Hamano  writes:

> Having said that, at least for this round, I do not think there is
> nothing to do at this point on your end;...

I obviously meant "I think there is nothing" here.  Sorry.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Stefan Beller  writes:

> This replaces sb/submodule-parallel-update.
> (which is based on sb/submodule-parallel-fetch)
>
> Thanks to Junio and Jonathan for review!
>
> * s/config_parallel_submodules/parallel_submodules/ as it is not in config any
>   more. Also ease up the default setting. 
>
> * use an enum for submodule update strategy

Your earlier sb/submodule-init will need to be rerolled on top, as
it depends on ->update being a string, I think.

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

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Beller]

On Tue, Feb 9, 2016 at 1:39 PM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> This replaces sb/submodule-parallel-update.
>> (which is based on sb/submodule-parallel-fetch)
>>
>> Thanks to Junio and Jonathan for review!
>>
>> * s/config_parallel_submodules/parallel_submodules/ as it is not in config 
>> any
>>   more. Also ease up the default setting.
>>
>> * use an enum for submodule update strategy
>
> Your earlier sb/submodule-init will need to be rerolled on top, as
> it depends on ->update being a string, I think.

Sure, I just want to prioritize this series as it is the bottleneck for all
other following things (init as well as the groups thing), I think.

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

>
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Stefan Beller  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html