<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 13, 2015 at 4:46 PM, Christopher Larson <span dir="ltr"><<a href="mailto:kergoth@gmail.com" target="_blank">kergoth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2s4" class="a3s" style="overflow:hidden">This only implements support for shallow mirror tarballs, not shallow clones.<br>
<br>
The mirror tarball filename includes branch, revision, and depth. To enable,<br>
use the `BB_GIT_SHALLOW` variable, or `BB_GIT_SHALLOW_<name>` for specific<br>
URLs. This variable can hold either a clone depth (e.g. `1` to just get<br>
SRCREV), or a ref or commit, in which case we keep history up to that commit.<br>
<br>
The shallow support will not, at this time, function correctly for<br>
linux-yocto, due to its branching scheme & validation.<br>
<br>
Example:<br>
<br>
BB_GIT_SHALLOW ?= "1"<br>
BB_GIT_SHALLOW_pn-linux-yocto = ""<br>
BB_GIT_SHALLOW_pn-linux-mel_mx6 = "v3.14"<br>
BB_GIT_SHALLOW_pn-testrepo = "testbranch"<br>
<br>
This implementation will attempt to fetch a full mirror tarball if it was<br>
unable to fetch a shallow tarball. If `BB_GIT_SHALLOW` and<br>
`BB_GENERATE_MIRROR_TARBALLS` are enabled for a given recipe, a shallow<br>
tarball will be emitted.</div></blockquote></div><br>The other thing I forgot to mention is that the shallow tarballs aren't unpacked into ${DL_DIR}/git2/ the way the full ones are, they're unpacked directly into the destination under ${WORKDIR}, to avoid complexities and confusion. This is why localpath() now returns the shallow tarball path when it exists, to avoid issues with checksums, and because we don't need/want download() to do anything else after it's fetched.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I just realized there's a slight inconsistency in the current behavior. When shallow and the shallow tarball exists, localpath() returns that path, but in the case where both ud.clonedir and the shallow tarball exists, the former will be unpacked, not the latter. I'll have to double check that the case where we have an existing out of date clonedir doesn't cause a shallow tarball to be fetched, otherwise it'll bypass updating the clonedir in download() and then unpack the out of date clonedir into workdir. If that's an issue, can make unpack() prefer the shallow tarball when shallow and the tarball exists, even if clonedir exists.<br>-- <br><div class="gmail_signature"><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div></div>
</div></div>