[arch-general] Why no git --depth=1 option for makepkg?

Eli Schwartz 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
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180304/f6f6049a/attachment.asc>


More information about the arch-general mailing list