github port group

[Craig Treleaven]

At 4:43 PM -0500 4/22/12, Ryan Schmidt wrote:
>On Apr 22, 2012, at 16:35, Joshua Root wrote:
>
>>  WFM:
>>
>>  % 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 
file comment.

So archiving a tree at different times would give different 
timestamps.  Archiving a commit always gets the same timestamp.

Craig