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
Attachment:
signature.asc
Description: OpenPGP digital signature
