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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 14.09.2011 00:17, schrieb Jeff King:
> 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.

I think this would work for the functionality which is implemented right
now. But with Frederik's gitfile work I hope to enable git to support
submodules being moved around in the work tree rather soonish. Then we
would be blind for any changes in the new location. Until it hurts us
I'd prefer to stay with the correct version, even if it is a bit slower.

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

No worries, nothing bad happens in that case.