Currently I believe you generate release archives by basically zipping up everything in the source directory except the .git* files/directories. Let me suggest a cleaner way: create a “manifest” file, following the format as documented here. Then you can use the make-snapshot script from my git-useful repo to generate a .zip file for any release. This reads the file contents directly from the commit history. For example, a suitable manifest file for the XNALaraMesh project could be
(Assuming the manifest file itself is called MANIFEST.in.) or, alternatively,
include *.py
recursive-include icons *
Then, to generate an archive for the v2.0.2 release, for example, you use a command like
make-snapshot -m MANIFEST.in XNALaraMesh v2.0.2
and this will create the release archive under the name XNALaraMesh-v2.0.2.zip. If you look in the archive, you will see that the top-level directory name is XNALaraMesh, and all the file timestamps come from the last commit that affected each one. This means that two different people with copies of the same Git repo should be able to produce bit-for-bit identical release archives for the same release, and a release archive for any past release can be exactly (re)created at any time.
Currently I believe you generate release archives by basically zipping up everything in the source directory except the
.git*
files/directories. Let me suggest a cleaner way: create a “manifest” file, following the format as documented here. Then you can use themake-snapshot
script from mygit-useful
repo to generate a.zip
file for any release. This reads the file contents directly from the commit history. For example, a suitable manifest file for the XNALaraMesh project could be(Assuming the manifest file itself is called
MANIFEST.in
.) or, alternatively,Then, to generate an archive for the v2.0.2 release, for example, you use a command like
and this will create the release archive under the name
XNALaraMesh-v2.0.2.zip
. If you look in the archive, you will see that the top-level directory name isXNALaraMesh
, and all the file timestamps come from the last commit that affected each one. This means that two different people with copies of the same Git repo should be able to produce bit-for-bit identical release archives for the same release, and a release archive for any past release can be exactly (re)created at any time.