Adding the following options to the .gitmodules file was also useful for speeding up routine git commands:

active = false

ignore = true

shallow = true

I am not sure if all of them are necessary - I don't profess to be a git wizard. I still had commands such as 'git add -u' hang.

Indeed --recurse-submodules is necessary (and might be why the CI is currently failing for the the PR).

Thanks,

Nicholas

On Mon, Feb 22, 2021, 04:23 Hans Dembinski <hans.dembinski@gmail.com> wrote:

Hi,

> On 22. Feb 2021, at 10:35, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>
> Ouch, that's a lot slower than I expected. I'm not sure I understand it though, there should be no `git status` churn at all (unless the build process messes with files in-place?) and it's faster than cloning our own repo:
>
> $ time git clone git@github.com:boostorg/boost.git
> Cloning into 'boost'...
> remote: Enumerating objects: 15, done.
> remote: Counting objects: 100% (15/15), done.
> remote: Compressing objects: 100% (11/11), done.
> remote: Total 254626 (delta 8), reused 11 (delta 4), pack-reused 254611
> Receiving objects: 100% (254626/254626), 62.02 MiB | 7.47 MiB/s, done.
> Resolving deltas: 100% (163071/163071), done.
>
> real 0m12.221s
> user 0m5.959s
> sys 0m2.725s

because of the a long-term goal to make boost more modular, cloning boostorg/boost like this only clones the so called superproject of Boost, which indeed very small. It consists itself of many submodules with the individual Boost libraries, like Boost.Math etc, which live in separate repositories. If you do

git clone --recurse-submodules git@github.com:boostorg/boost.git

instead, you will see the long delay. Fetching all the submodules indeed takes a lot of time, unfortunately. The main Boost repo includes 157 submodules.

Best regards,
Hans
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev