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 previous email. 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 ten commits).
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) specified.
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. -- Eli Schwartz Bug Wrangler and Trusted User