On 3/4/18, Eli Schwartz <eschwartz@archlinux.org> wrote:
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).
Right. I had assumed that git clone -b/--branch did also exist for tags. Git is like Linux and very evolutionary, with many warts, only some parts designed before implementation. This means some features are only implemented partially. I like and use git, but sometimes it feels like it's a car where there are five doors, but you're only supposed to use 2.5 of them.
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).
See above.
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.
svn works differently, whereas git is all about the DAG. But let's not discuss svn's design. The idea was that when you the ability to svn checkout a github project or maybe Apache svn repository, and those have proper tags and branches, then this will be very quick in comparison. But as you say, this is bound to be problematic for other reasons. I believe git devs are working on checking out tags with shallow depth, not sure how many years it will take.
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.
Let's ignore the possibility of svn, but tracking a revision number is the same for those projects without tags as it is for git. As in the xf86-video-intel project.