Here's how I was told the correct way to handle it was: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mono-git#n57
I've got a few more that use git submodules as well: ags-git and rofi-git are ones I know offhand. > Implement noextract=() for source/git.sh to avoid having two checkouts with that ugly layer of indirection. +1 On Mon, Jul 31, 2017 at 2:52 PM Eli Schwartz <eschwa...@archlinux.org> wrote: > On 07/31/2017 03:35 PM, Doug Newgard wrote: > > On Mon, 31 Jul 2017 14:16:33 -0400 > > Eli Schwartz <eschwa...@archlinux.org> wrote: > >> You're both right and wrong. "$srcdir/$submodulename" will be at > >> origin/master, but `git submodule update` in the primary repo will > >> completely ignore that clone altogether and just cares about the git > >> objects which it uses in yet another clone. > >> > > > > This is a bit confusing. You set the URL of the submodule to the > location of > > the local clone, so it doesn't ignore it, it just clones from the local > clone. > > And yes, it does use the specific commit specified in the main repo, so > setting > > #commit= for the submodule is useless. > > Yeah, that. Although now I am starting to think... > > I don't have any PKGBUILDs that do this myself. So it's never really > been on my radar. However, I am wondering if it would make more sense to > allow/use: > - $SRCDEST/$repo for the submodule url. The variable should be > accessible, we just don't document its availability for use in a > PKGBUILD. > - Implement noextract=() for source/git.sh to avoid having two checkouts > with that ugly layer of indirection. > - Update the "VCS package guidelines" wiki page > > -- > Eli Schwartz > >