Allow for shallow updates

For verification purposes, it would be nice to init and fetch only versions from the manifest file. So issuing:

west init
west update --shallow

or

west init --shallow
west update

Would create a minimal version of repository saving a lot of time for big projects.

[marc-hb]

@mbolivar-nordic just abandoned #475 and I’m not sure why.

I think giving #475 and #344 a name should help clarify concepts, I suggest “narrow”. I see roughly 4 classes of git clones in general use (with and without west)

• LARGE git clone; git fetch --tags Slowest, biggest and best for airplane trips mentioned in #475. Current west default.

• git’s DEFAULT git clone; git fetch All remote branches. “Opportunistic” tags only.

• NARROW git clone --no-tags --single-branch git fetch ref_name_or_SHA Maximum optimization without breaking any git command. Savings can be huge in projects with many branches.

• DEPTH1 a.k.a. “shallow” git clone --depth 1 Maximum savings and most git commands are broken by design. For CI and repetitive throw-away clones only, best avoided for persistent clones. In git’s documentation “shallow” means “truncated”, it does not mean depth 1. Git terminology can be confusing enough, better not diverge from it when not necessary.

Thanks to custom refspecs, intermediate --depth, different clone+fetch combinations, different git versions etc. the reality is not just these 4 points but actually a spectrum. However I think these 4 points should capture most real-world use cases and that these are the concepts west should present, not just DEPTH1.

The big difference fetch-pack’s uploadpack.allow*SHA1InWant makes: it simply forbids NARROW and DEPTH1 and forces a fallback on LARGE or DEFAULT (with a warning?) when what you want is a SHA1 instead of a tag or branch. #344 explored a revision-in trick to fall back on NARROW.

[czeslawmakarski]

@tejlmand Yes, I think that speeding-up the CI is the priority right now, so, no changes in manifest format, just a --shallow switch and west config to enable direct SHA fetching in the repos.

@marc-hb I see your reasoning - having discrepancies in the west.yml’s can be indeed a nightmare. For the time being let’s stick with the west config phase.