Addition of 'SVN-keywords' like functionality with Download

Create issue
Issue #12 wontfix
Jonathan Adcock created an issue

I'm currently using Stash for the development of vba, python and other scripts. Authors and other members of the team would use git in the normal way to track version histories and make changes, but I'd also like users who just want the files to use the Download button to grab copies. These people are not git users so it seems like a good way of distributing code without having a separate location that we have to maintain.

The git-archive feature works well for this, however there is no way of knowing the revision or origin of the files once you've created that zip file. SVN has keywords that can automatically write info like $author$, $Id$ etc in to the file header on commit. I know git doesn't have this functionality, but I have written a bash script that can write info like this into a file header as part of a git-archive process. The script looks for tags like $Last Update:$, $Comment:$ and $Hash:$ and uses the git log to replace these tags with info about the author, date modified etc. It would be really useful if functionality like this could be available as part of the stash-archive plugin.

Just wondering if anyone else has a similar use case, or any thoughts about this proposal? I've attached the bash script I use to do this using shell/git locally, but I've no idea really the work involved to incorporate this into the plugin...

Comments (2)

  1. Bryan Turner Account Deactivated

    git archive includes a pax header in tarballs, and a file comment in zip files, with the commit ID that was archived. From the commit ID, it's possible to look up the full commit details. For example, here's a zip archive:

    Aphrael:tmp bturner$ unzip -z ../ 
    Archive:  ../
    Aphrael:tmp bturner$ git show b4283fea3219cfd06f0391c459309768933aafab
    commit b4283fea3219cfd06f0391c459309768933aafab
    Author: Bryan Turner <>
    Date:   Wed May 4 15:19:20 2016 -0700

    The tarballs/zips created by this plugin are not "staged" to disk. This is a very important implementation detail, because the archives may be of an unknown size. Unpacking them to add these attributes may require a substantial amount of server resources--briefly, hopefully, but for repositories containing tens of thousands of files the I/O for this may become prohibitve. Given that, we will not be adding any attributes beyond what Git itself already embeds in the archive. Further commit details are available in the UI.

  2. Log in to comment