Partial clone breaks offline usage with `clang.sh` about alibuild

[TimoWilken]

As I understand it, --filter=blob:none explicitly doesn't fetch file contents, saving bandwidth on the initial clone. On checkout, those file contents need to be fetched, though, hence the network traffic in 2b.

If we only need a specific commit to build, perhaps it would be better to use something like git clone -b <commit> --depth 1 <url> instead? As far as I can tell, we don't use the commit history, right? @ktf?

I can't reproduce the long runtimes of the git fetch commands locally (I manually cloned the repos, but I can't see anything obvious that aliBuild is doing differently; git 2.31.1 also).

[dennisklein]

I can't reproduce the long runtimes of the git fetch commands locally (I manually cloned the repos, but I can't see anything obvious that aliBuild is doing differently; git 2.31.1 also).

You are right! I re-checked and now it is fast for me as well (both with aliBuild and with manual git command sequence). I guess, it must have been a temporary issue - possibly with my internet connection or due to some service degradation (on weekends)? (I frequently see very slow connections to the geant4 cern gitlab on weekends, too). Sry for the noise here!

we only need a specific commit to build, perhaps it would be better to use something like git clone -b <commit> --depth 1 <url> instead? As far as I can tell, we don't use the commit history, right?

Hmm, having thought about it a bit more, I would prefer a simple switch to disable partial clones (does it already exist?) - default behavior can stay at it is - next time I find some time, I can propose a PR for such a switch, if you want, it is not urgent. That said, I don't think shallow clones (--depth 1) are a good idea to save space/traffic for the MIRROR clones (I know some repos where the build systems queries the source tree via git - that is actually one quality of aliBuild I value very much; that it has first class git integration in contrary to other package managers - I would love to not see this gone ;) ).

[ktf]

Indeed, --filter blob:none is actually what we want: the whole history, without the full cost of the history, unless explicitly requested. Maybe we should check if there is something which triggers a big fetch. It could also depend of the way the blobs are stored (you always get a pack, not a single blob, so if llvm uses large packs, you might end up downloading more than you wanted).