Zip archive to include submodule

When possible (accessibility-wise), would be nice if submodules are packed in the zip archive of branch.

For example:

# in Windows PowerShell
cd /temp
wget https://github.com/Snaipe/Criterion/archive/bleeding.zip -OutFile criterion-bleeding.zip
Expand-Archive criterion-bleeding.zip -DestinationPath .

# now compare
ls -r criterion-bleeding/dependencies
# with
cat criterion-bleeding/.gitmodules

tells us Criterion has three submodules listed in .gitmodules file which were not included in the zip archive.

Including submodules in releases would also be nice.

Any chance? :)

Big +1 from me! Submodules are cumbersome as it is, but the fact that they're not included in the zip makes it impossible to use submodules in a project you want to distribute via unadorned source downloads on GitHub.

Alleged answer of the github about the subject (posted in https://blogs.harvard.edu/acts/2012/10/18/github-zip-doesnt-include-submodules/#comment-975):

Currently zip/tarballs are generated using git-archive, which does not include submodules. If the git team adds that functionality to git-archive, we’ll be sure to update it so we can include submodules as well.

Looking at the git-documentation does not show me something about support of submodules...

The issue is also related to: the referenced modules are revisions-pinned (different branches could have different submodules and/or could address different commits within); they could be recursive (have submodules too), etc.

Has this been solved? It would be awesome to have the submodules in the ZIP downloads and releases:(

This is probably something for upstream, I.e. git. About pinning etc, simples would be to effectively do git submodule update —init —recursive, which is the first thing I do in any of my repos

Sure, but many people come to GIT just for the software, and dont know what git is. The 'Download ZIP' button, therefore defeats its purpose. Anyways, this is truly for Git to solve.

There is a third-party alternative that will archive all submodules together: https://github.com/Kentzo/git-archive-all

This would be super cool

bugfix: remove submodule

Not only is this "nice to have", it's actually quite a support nightmare for me on all of my projects with submodules. I get regular complaints, no matter how many times I post DO NOT USE THE GITHUB SOURCE ZIP FILES.

Requiring end users of the repositories to learn the intricacies of git and rebuild the project structure in order to casually test a project because Github couldn't be chuffed customizing some code instead of just wrapping git-archive is BAULKED

To be honest, git submodules are one of the worst nightmares for linux distribution package maintainers.
People should use plain old libraries instead of git submodules.

To be honest, git submodules are one of the worst nightmares for linux distribution package maintainers.
People should use plain old libraries instead of git submodules.

Though I myself am on this page because of a package I'm maintaining, submodules can still be useful. Especially on non-Linux systems, where the library system is abysmal. But even on Linux, for header-only libraries or similar things, submodules are fine.

Anyway, having source archives include submodules is logical. Anyone who wants the source code to a project should have all the necessary pieces to build it. If there are concerns as to file sizes, there could be radio buttons to choose whether to recursively include submodules. These buttons could simply add or remove an option in the URL to the archive. This would be enough for package maintainers, as they could use the URL for recursive submodule cloning.

Update README.md

That's why we still keep zip-ing the source code and including it to git. 21st century

I think people should contribute to projects like gitea instead of begging microsoft for a functionality.
Big tech doesn't listen to people. It's also a good idea to move your repositories out of github.

in case someone is looking for a workaround:
for me github action that creates draft release with customr artifact works like charm: https://github.com/mrl5/vulner/blob/d67baade397c650fde6edb7e183e9fa638b40a06/.github/workflows/draft-release.yaml

# https://github.com/actions/create-release
# https://github.com/actions/upload-release-asset
name: draft-release

on:
  push:
    tags:
      - 'v*'
env:
  CARGO_TERM_COLOR: always

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true

      - name: Get custom tarball name
        id: get_tarball_name
        run: echo ::set-output name=TARBALL_NAME::vulner-${{ github.ref_name }}

      - name: Get archived folder name for custom tarball
        id: get_archived_folder_name
        run: echo ::set-output name=ARCHIVED_FOLDER::${{ github.repository_owner }}-vulner-$(git rev-parse --short HEAD)

      - name: Create custom tarball artifact
        run: |
          mkdir -p artifacts
          tar czhvf \
            artifacts/${{ steps.get_tarball_name.outputs.TARBALL_NAME }}.tar.gz \
            --exclude="*metarepo-cpe-tag*" \
            --directory=../ \
            vulner/crates/ vulner/Cargo.lock vulner/Cargo.toml vulner/Makefile vulner/scripts/ vulner/README.md vulner/LICENSE \
            --transform s/vulner/${{ steps.get_archived_folder_name.outputs.ARCHIVED_FOLDER }}/
      - name: Build from custom tarball artifact
        run: |
          mkdir -p build
          tar xzvf artifacts/${{ steps.get_tarball_name.outputs.TARBALL_NAME }}.tar.gz \
            --directory=build
          cd build/${{ steps.get_archived_folder_name.outputs.ARCHIVED_FOLDER }}
          make build
      - name: Create draft release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: ${{ github.ref }}
          body: |
            DRAFT
          draft: true
          prerelease: true

      - name: Upload TAR.GZ release asset
        id: upload-tar-gz-release-asset
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./artifacts/${{ steps.get_tarball_name.outputs.TARBALL_NAME }}.tar.gz
          asset_name: ${{ steps.get_tarball_name.outputs.TARBALL_NAME }}.tar.gz
          asset_content_type: application/gzip

Here's my Github Action to do this:

https://github.com/ahalekelly/Dettlaff/blob/master/.github/workflows/nightly-release.yaml

name: nightly-release

on:
  push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true

      - name: Create zip
        run: |
          cd ..
          zip ${{ github.event.repository.name }}/${{ github.event.repository.name }}-nightly.zip ${{ github.event.repository.name }} -r
          
      - uses: pyTooling/Actions/releaser@r0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          tag: nightly
          files: ${{ github.event.repository.name }}-nightly.zip

I understand why including submodules in the generated ZIP could be problematic. On the other hand, source in the ZIP without submodule sources is of little use, and as noted above, just confuses many people.

What I do not understand is why GitHub does not at least show a loud and clear warning before downloading a ZIP for a repository with submodules.

Was there an official GitHub concrete response to this problem, I could not find any and this Issue has been open for over 5 years?

dev-libs/gost-engine: fix build

I just want to notice that the git submodules does not support several git features as a builtin like sparse checkout or sparse recursion additionally to recursion flag in a command. You still must rely on some external tool and storage, for example, like vcstool to use alternative (and much more advanced) variant of external dependencies to checkout them. This brings alternative custom .submodules file and requires to supersede the clone command.

So as a result the archive command can not take out submodules correctly (no sparse support) and it's implementation actually never would be enough complete and applicaible.

Currently the vcstool project does not have a sparse checkout implemented, but it's fork has:

dirk-thomas/vcstool#218
https://github.com/dirk-thomas/vcstool/pull/219/files

So as a result the archive command can not take out submodules correctly (no sparse support) and it's implementation actually never would be enough complete and applicaible

That all is mostly irrelevant by simplest downloading of archive for some branch on GH. But also if it it would be relevant for 0.01% of all cases, it'd work for 99.99% where a submodules must be included to archive one-to-one, without to take care about that "several git features".
At the moment it simply doesn't work for 100% of all repos with submodules.

build: 🔥 remove git modules

build: 🔥 removed git modules (#273)

Automate upload of release archives

Automate upload of release source archives

Automate upload of release source archives (#24)

+1 from Nixpkgs maintainer.

Navigation Menu

Repository navigation

Zip archive to include submodule #214

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Zip archive to include submodule #214

Description

Activity

rschuetzler commented on Nov 2, 2017

maddanio commented on Mar 20, 2018

obskyr commented on Jan 30, 2019

sebres commented on Jan 30, 2019

gergelytakacs commented on Apr 28, 2019

maddanio commented on Apr 28, 2019

gergelytakacs commented on Apr 29, 2019

tadeu commented on Oct 3, 2019

syedmohsinbukhari commented on Dec 1, 2019

phillipjohnston commented on Sep 17, 2020

norlesh commented on Nov 9, 2020

crocket commented on Mar 16, 2021

ZLima12 commented on May 1, 2021

5 remaining items

tenbits commented on Feb 23, 2022

crocket commented on Feb 24, 2022

mrl5 commented on Mar 6, 2022

ahalekelly commented on Mar 27, 2022

PBfordev commented on Apr 24, 2022

andry81 commented on Feb 24, 2023

sebres commented on Feb 27, 2023

Endermanbugzjfc commented on Aug 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions