[arch-general] Why no git --depth=1 option for makepkg?
eschwartz at archlinux.org
Sun Mar 4 20:50:31 UTC 2018
On 03/04/2018 03:27 PM, Carsten Mattner wrote:
> Interesting. What does PKGBUILD do with history of more than 10 revisions?
> If we checkout a tag or specific commit (e.g. xf86-video-intel), what
> does PKGBUILD need prior revisions for? I'm sure you're correct, I'd
> like to know what it is, if you don't mind explaining.
You cannot clone a tag or commit, you can only clone a branch and check
out the tag or commit. So you need enough revisions on that branch to
reach said tag... and you cannot use shallow-exclude as I mentioned in a
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).
>> depth=10 will only work for tags that are present in the last ten
>> commits, which unsurprisingly is exactly the opposite of most projects
>> (which don't have tags at all and therefore require all history without
>> exception in order to implement the pkgver() function) or even most
>> projects with tags (which don't release stable releases on basically
>> every other commit).
> Eli, you certainly have more experience, so I'm trusting your word here.
> However, I don't understand how depth=10 can fail when trying to checkout
> a specific git tag. Wouldn't the tag be the HEAD in that case?
If that were true, then depth=1 would work. But tags are usually not the
upstream HEAD commit, because development continues afterwards...
So first you clone a branch, and then you try to checkout a tag (and
fail, if you used depth=10 and the tag is not attached to one of those
> Checking out with SVN is a speedup trick, and I still think it can make
> sense if depth limiting git clone is not possible. svn checkout is
> basically just copying the tree of that revision (or branch/tag path)
I know how SVN works. :p
I also know how svn doesn't work -- you cannot get tag information, for
example, and svn revision numbers do not necessarily cleanly translate
to git revisions numbers let alone commit hashes.
Giving users a mysterious svn revision number they don't know how to
trace, is confusing UI. So I wouldn't recommend this even for projects
without tags at all.
Bug Wrangler and Trusted User
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the arch-general