Carles Pina i Estany wrote: > Actually, the first time I wondered if the connection or something else > failed.
The latter is a user mistake, since there was a message "Cloning into '/home/carles/git/wget2/gnulib'..." and the "..." tells that it may take some time. > When I say "long time" (and data transmission) in my case it's 9 > minutes: > ----- > carles@pinux:[master]~/git/wget2$ time git submodule update --init > Cloning into '/home/carles/git/wget2/gnulib'... > Submodule path 'gnulib': checked out > '2ae6faf9c78384dc6a2674b62dd56ff153cd51f6' > > real 9m1,135s > user 6m24,309s > sys 0m5,020s > ----- I can reproduce that the --depth option has a big impact on the 'git clone' execution time: - no --depth: 50 sec. - --depth=2000: 16 sec. - --depth=1: 5 sec. However, --depth=1 has the problem that it may/will cause trouble to the developer later, if they use more than "git pull". Namely, - In 'git log' the history will be truncated, - 'git bisect' may not work, - 'git annotate' will show a wrong author for many lines of code. '--depth=2000' would be a middle ground, but it still has the 'git annotate' problem. These troubles are probably not worth the saved 'git clone' time upfront. However, when doing automated builds, such as continuous integration, --depth=1 saves a lot of time, and is not problematic, since the build directory is getting deleted anyway 10 minutes later. How about adding to 'bootstrap' an option '--for-build' that has the effect that all submodule clones will be fetched with --depth=1 ? Tim Rühsen wrote: > To speed things up in container CI environments: > If containers are only used once, git clone gnulib at image creation > time and do "rmdir gnulib && mv /gnulib . && git submodule update > gnulib" in the container. Nice trick. Let's see how it competes with with a --depth=1 option. I would expect that if you use the same image for a year, the 'git submodule update gnulib' step gets slower and slower over that year, until you create a new image. Bruno
