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

Re: [PATCH 05/12] git submodule update: Use its own list implementation.

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 16, 2015, 21:02 UTC
Message-ID
<xmqqy4f2cysl.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<1444960333-16003-6-git-send-email-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
Show 11 quoted lines
> Discussions turned out that we cannot parallelize the whole loop below
> `git submodule--helper list` in `git submodule update`, because some
> changes should be done only one at a time, such as messing up a submodule
> and leave it up to the user to cleanup the conflicted rebase or merge.
>
> The submodules which are need to be cloned however do not expect to create
> problems which require attention by the user one at a time, so we want to
> parallelize that first.
>
> To do so we will start with a literal copy of `git submodule--helper list`
> and port over features gradually.
I am not sure what you mean by this.

Surely, the current implementation of "update" does the fetching and updating as a single unit of task and iterate over these tasks, and we would rather want to instead have one iteration of submodules to do the fetching part (without doing other things that can fail and have to get attention of the end user), followed by another iteration that does the "other things", in order to get closer to the end goal of doing the fetch in parallel and then doing the remainder one-module-at-a-time sequencially.

I would imagine that the logical first step towards the end goal, if I understood you correctly, would be to split that single large loop that does a fetch and other things for a single module in each iteration into two, one that iterates and fetches all, followed by a new one that does the checkout/merge.

What I do not understand is why that requires a different kind of enumerator (unless this is a kind of premature optimization, knowing that the set of modules iterated by these two loops are slightly different or something).

Show 14 quoted lines
>  int cmd_submodule__helper(int argc, const char **argv, const char *prefix)
> diff --git a/git-submodule.sh b/git-submodule.sh
> index bb8b2c7..d2d80e2 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -656,7 +656,7 @@ cmd_update()
>  	fi
>  
>  	cloned_modules=
> -	git submodule--helper list --prefix "$wt_prefix" "$@" | {
> +	git submodule--helper list-or-clone --prefix "$wt_prefix" "$@" | {
>  	err=
>  	while read mode sha1 stage sm_path
>  	do
Previous: Stefan BellerNext: Stefan Beller
Message 11 of 21 in “[RFC PATCHv1 00/12] git submodule update in C with parallel cloning”
  1. Stefan BellerOct 16, 2015
  2. 01/12 git submodule update: Announce skipping submodules on stderrStefan Beller, Oct 16, 2015
  3. Junio C HamanoOct 16, 2015
  4. Stefan BellerOct 16, 2015
  5. 02/12 git submodule update: Announce uninitialized modules on stderrStefan Beller, Oct 16, 2015
  6. Junio C HamanoOct 16, 2015
  7. 03/12 git submodule update: Move branch calculation to where it's neededStefan Beller, Oct 16, 2015
  8. Junio C HamanoOct 16, 2015
  9. 04/12 git submodule update: Announce outcome of submodule operation to stderrStefan Beller, Oct 16, 2015
  10. 05/12 git submodule update: Use its own list implementation.Stefan Beller, Oct 16, 2015
  11. Junio C HamanoOct 16, 2015
  12. Stefan BellerOct 16, 2015
  13. 06/12 git submodule update: Handle unmerged submodules in CStefan Beller, Oct 16, 2015
  14. Junio C HamanoOct 20, 2015
  15. Stefan BellerOct 20, 2015
  16. 07/12 submodule config: keep update strategy aroundStefan Beller, Oct 16, 2015
  17. 08/12 git submodule update: check for "none" in CStefan Beller, Oct 16, 2015
  18. 09/12 git submodule update: Check url in CStefan Beller, Oct 16, 2015
  19. 10/12 git submodule update: Clone projects from within CStefan Beller, Oct 16, 2015
  20. 11/12 submodule--helper: Do not emit submodules to process directly.Stefan Beller, Oct 16, 2015
  21. 12/12 WIP/broken Clone all outstanding submodules in parallelStefan Beller, Oct 16, 2015

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.