git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 11, 2016, 20:23 UTC
Message-ID
<xmqqlh6rvvwb.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<xmqqziv91qzi.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 32 quoted lines
> Stefan Beller <sbeller@google.com> 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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 28 of 30 in “[PATCHv9 0/6] Expose submodule parallelism to the user”
  1. Stefan BellerFeb 9, 2016
  2. 1/6 submodule-config: keep update strategy aroundStefan Beller, Feb 9, 2016
  3. Junio C HamanoFeb 9, 2016
  4. Stefan BellerFeb 9, 2016
  5. Junio C HamanoFeb 9, 2016
  6. Jonathan NiederFeb 9, 2016
  7. Junio C HamanoFeb 9, 2016
  8. Junio C HamanoFeb 11, 2016
  9. 2/6 submodule-config: drop check against NULLStefan Beller, Feb 9, 2016
  10. Jonathan NiederFeb 9, 2016
  11. 3/6 fetching submodules: respect `submodule.fetchJobs` config optionStefan Beller, Feb 9, 2016
  12. Junio C HamanoFeb 9, 2016
  13. Jonathan NiederFeb 9, 2016
  14. Stefan BellerFeb 10, 2016
  15. Junio C HamanoFeb 10, 2016
  16. Junio C HamanoFeb 10, 2016
  17. 4/6 git submodule update: have a dedicated helper for cloningStefan Beller, Feb 9, 2016
  18. Junio C HamanoFeb 9, 2016
  19. Jonathan NiederFeb 10, 2016
  20. Jacob KellerFeb 10, 2016
  21. Stefan BellerFeb 10, 2016
  22. Jacob KellerFeb 11, 2016
  23. 5/6 submodule update: expose parallelism to the userStefan Beller, Feb 9, 2016
  24. 6/6 clone: allow an explicit argument for parallel submodule clonesStefan Beller, Feb 9, 2016
  25. Junio C HamanoFeb 9, 2016
  26. Stefan BellerFeb 9, 2016
  27. Junio C HamanoFeb 9, 2016
  28. Junio C HamanoFeb 11, 2016
  29. Junio C HamanoFeb 11, 2016
  30. Stefan BellerFeb 11, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.