Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules

> One thing that could make it slightly less expensive (but I wouldn't
> worry about implementing until it becomes an issue): you do a full diff
> and collect any changed GITLINK entries, and then compare the paths we
> get with the submodule config. Couldn't you instead do something like
> this:
> 
>   - let S = set of submodule paths that we care about, from the config
>   - start the "git rev-list $new --not $old" traversal, as we do now
>   - for each commit
>     - diff using a pathspec of S
>     - for each changed entry
>       - add it to the set of changed submodules
>       - remove it from S
>     - if S is empty, break
> 
> That has two advantages:
> 
>   1. We limit the diff by pathspec, which means we can avoid looking at
>      irrelevant parts of the tree (we don't do this yet, but hopefully
>      we will in the future).
> 
>   2. You can break out of the traversal early if you already know you
>      have changes in each submodule of interest.

> Out of curiosity, what happens if we don't have such a commit? I know
> you said that your policy is never to rewind a submodule's commit that
> has been published in a superproject, and I think that's the only sane
> thing to do. But it's not enforced by git itself, and I wonder how badly
> we break if it does happen (i.e., I'm hoping the answer is "you can't
> diff or checkout superproject revisions that reference the missing bit"
> and not "git log crashes when it gets to that point in history").