>On Apr 22, 2012, at 16:35, Joshua Root wrote:
>> % openssl sha1 1/file.tar 2/file.tar
>> SHA1(1/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
>> SHA1(2/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
>> % gzip 1/file.tar
>> % gzip 2/file.tar
>> % openssl sha1 1/file.tar.gz 2/file.tar.gz
>> SHA1(1/file.tar.gz)= 78020f5e126da22be27ac9eda2633db59b725480
>> SHA1(2/file.tar.gz)= 78020f5e126da22be27ac9eda2633db59b725480
>> Do your two input files also have identical timestamps?
>Ah, you're right, they did not. Now I get the same sums, if both
>files have not only the same name but also the same timestamp.
>So I guess what a service like bitbucket would have to do when it
>generates a tarball is to set its timestamp to the timestamp of the
>requested revision before gzipping it.
Regarding timestamps, the man for git archive says:
git archive behaves differently when given a tree ID versus
when given a commit ID or tag ID. In the first case the current time
is used as the modification time of each file in the archive. In the
latter case the commit time as recorded in the referenced commit
object is used instead. Additionally the commit ID is stored in a
global extended pax header if the tar format is used; it can be
extracted using git get-tar-commit-id. In ZIP files it is stored as a
So archiving a tree at different times would give different
timestamps. Archiving a commit always gets the same timestamp.