hmm.. not true sometimes. I will just post the definition here because I feel people dont understand shallow clone well. The --depth 1 option in git clone: Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. so, 1. you can also do the "pull once use forever" 2. you cannot push to that repo anymore (but who really needs to anyway?) the only drawback i can see: 1. the git rev-list count head hack does not work. but should we just clone the whole thing for the pkgver? (notice, for example, tweeter bootstrap: 26mb vs 3mb with shallow clone) On Fri, Apr 5, 2013 at 6:41 AM, Uwe Koloska <kolewu@koloro.de> wrote:
Am 05.04.2013 08:12, schrieb Tai-Lin Chu:
1. save bandwidth 2. less wait
why not add --depth 1 :)
because you can't do nearly anything git related with this clone. You can't clone, can't update, etc.
Best workflow is * clone the repo (like downloading a source package) * on all following calls do an update * then do a clone to do the build (even here without '--depth 1' because local clones are cheap) * before the next build only remove the build-clone
With this workflow you only need to clone the repo once and then work with your local copy.
I don't know exactly what automatic the new makepkg implements for repository sources, but I think it will do the first two steps above.
So the PKGBUILD only has to provide the clone for the build (if the sources are not prepared for out-of-source builds).
Hope this helps Uwe