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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
