git fetch now causes all submodules to fetch, slowly

[Vincent Scheib]

git fetch origin has started also fetching submodules, even on unmanaged git, and does it slowly.

Often I'm fetching from origin to check log history, or to quickly fix up a patch to apply cleanly, and do not have a need to pull submodules. I dislike paying this time cost when I'm not running gclient sync or trying to update DEPS.

Is this required, or a side effect that can be undone?

[Ryan Sleevi]

A huge +1 to this.

Seems that this behaviour was introduced in http://crrev.com/189026 -
was it intentional to have this big an effect on workflow?

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>
>

[Bernhard Bauer]

Hm, that CL is modifying gclient, whereas Vincent was talking about a pure git fetch. I assume it has something to do with the submodule configuration (for me, git fetch fetches some of the submodules, but not all of them).

Bernhard.

[Ryan Sleevi]

The CL updates your .git/config to tell git to recursively fetch submodules.

Reverting that change (and the changes gclient makes to your
.git/config) restores the original behaviour.

[John Abd-El-Malek]

+Stefan

What I really needed was the "clone_cmd.append('--recursive')" part. Stefan suggested adding "fetch.recurseSubmodules" so that if a developer fetches manually it also works.

I don't have strong feelings here, other than the first part needs to work (otherwise bring in git repos through DEPS doesn't bring in the whole thing).

Stefan: wdyt?

[Stefan Zager]

On Thu, Mar 21, 2013 at 1:20 PM, John Abd-El-Malek <j...@chromium.org> wrote:

+Stefan

What I really needed was the "clone_cmd.append('--recursive')" part. Stefan suggested adding "fetch.recurseSubmodules" so that if a developer fetches manually it also works.

I don't have strong feelings here, other than the first part needs to work (otherwise bring in git repos through DEPS doesn't bring in the whole thing).

Stefan: wdyt?

I think we want to keep both the --recursive flag and the fetch.recurseSubmodules bits, but we don't want to apply them at the top level.

Stefan

[Jói Sigurðsson]

Sounds good to get this solved. For non-managed workflow, having [ git
pull ] and [ git fetch ] recursively fetch all submodules is very
painful.

Cheers,
Jói

[John Abd-El-Malek]

Are you able to make this change? I would but I'm not familiar with this stuff (I'm still not sure I understand how the problem is occurred, since I thought the change I did would only apply to submodules of submodules).

 

Stefan

[Henrik Andreasson]

Just checking if any work is ongoing here. It still takes more than 15 minutes for me to run gclient sync on Windows.

[Nico Weber]

On Sun, Mar 24, 2013 at 2:46 AM, Henrik Andreasson <hen...@chromium.org> wrote:

Just checking if any work is ongoing here. It still takes more than 15 minutes for me to run gclient sync on Windows.

From another thread: Improving this is tracked at http://crbug.com/224074

[Roland McGrath]

On Thu, Mar 21, 2013 at 1:36 PM, Stefan Zager <sza...@google.com> wrote:
> I think we want to keep both the --recursive flag and the
> fetch.recurseSubmodules bits, but we don't want to apply them at the top
> level.

I just tried changing fetch.recurseSubmodules to on-demand and that
makes 'git pull' fast again in the common case, while probably covering
the situations that motivated the setting.