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

Adam Levy theadamlevy+archlinux at gmail.com
Sun Mar 4 01:12:52 UTC 2018

> It provides a now dead link because there is a rogue space character
> ("Use r"). The following link works:

Thank you Tinu Weber. Silly oversight on my part.

After reading the discussions in previous feature requests the answer is
pretty clear. It could break some packages if used incorrectly and the same
functionality can be achieved by manually cloning the repo.

Thanks all for the responses.

On Sat, Mar 3, 2018, 3:07 PM Eli Schwartz via arch-general <
arch-general at archlinux.org> wrote:

> On 03/03/2018 12:50 PM, Jonathon Fernyhough wrote:
> > On 03/03/18 08:48, mike lojkovic via arch-general wrote:
> >> It would be extremely nice to have shallow clone support for some
> packages.
> >> The Unreal git repo requires pulling down 20 gigabytes for a build,
> taking
> >> maybe a half hour each time.
> >>
> >
> > An effective workaround is to create a shallow clone prior to running
> > makepkg,
> >
> > $ cd $SRCDEST
> > $ git clone --bare --depth=1 https://github.com/cisco/ChezScheme.git
> > ChezScheme
> > $ cd ChezScheme
> > $ git config remote.origin.fetch "+refs/*:refs/*"
> >
> > and away you go.
> >
> > However.
> >
> > You can't just use --depth=1 on everything without running into "weird"
> > problems. For example, any VCS package that relies on tags for its
> > pkgver will fail to find the last tagged commit, and so the fetch depth
> > must be increased to extend to the tagged commit.
> Yep -- more or less this. There is no way for git to fetch "all commits
> since a given tag", and obviously `git describe` which is used in the
> standard pkgver() function cannot describe the remote repository... not
> to mention what happens when the repository has *no* tags, and git
> rev-list --count HEAD depends on all commits since the repository was
> initialized.
> Then there is the fact that --depth, or even --single-branch (not that
> this usually saves much space or time), will break on PKGBUILDs that use
> `git cherry-pick` to backport fixes (more commonly seen in non-VCS
> packages obviously).
> All in all, there is simply no way to generically support shallow clones
> in a generic way. The best you can do is take a given PKGBUILD, predict
> what it needs, and perform the clone manually according to handpicked
> criteria as makepkg will detect that clone and then simply fetch new
> changes which respects a previous shallow clone designation.
> --
> Eli Schwartz
> Bug Wrangler and Trusted User

More information about the arch-general mailing list