On 03/04/2018 07:13 PM, Damjan Georgievski via arch-general wrote:
This means that PKGBUILDs which checkout a specific revision are actually worse than the rest, as you cannot even get the source without knowing how many commits you need (rather than failing afterwards in pkgver() or something).
Right. I had assumed that git clone -b/--branch did also exist for tags.
https://www.kernel.org/pub/software/scm/git/docs/git-clone.html
--branch can also take tags and detaches the HEAD at that commit in the resulting repository.
... huh, I stand corrected. :D I did not realize this was possible -- I've looked at clone depth fairly often but never noticed this... well, you live and learn! This actually makes it pretty easy to clone what you need in a stable PKGBUILD that checks out a tag (but not one that checks out a commit). Although it makes it no easier to also grab commits that are cherry-picked in prepare() or get the output of `git describe` for an unpredictable number of commits since and including a tag, which are also significant blockers. And these cannot be syntactically parsed from the source=() which means they would require PKGBUILD metadata to either indicate if it is safe to shallow clone or (manually specify) e.g. a date or tag-1 to fetch commits since. Probably still too much effort to implement... This would in theory be totally feasible if makepkg had a builtin feature to apply patches (which I think would be considered a "this is doing too much" feature) in addition to some way to reverse the pkgver() function to acquire the tag used in pkgver= and then specify git clone --shallow-since=${tag}~1 but at this point it becomes understandable why no one has any interest in implementing it. :) -- Eli Schwartz Bug Wrangler and Trusted User