It seems git archive creates a tarball with wrong file modification timestamps, resulting in tar complaining when unpacking:

$ cd repository
$ git archive -o repository.tar.gz master .
$ find /target/dir -type f -delete
$ tar -C /target/dir -xvf repository.tar.gz
tar: some/file.txt: time stamp 2014-10-29 13:09:52 is 49.814349986 s in the future
tar: another/file.txt: time stamp 2014-10-29 13:09:52 is 49.813794938 s in the future

This all happens within seconds on a single machine.

  • 1
    The timestamps in the tar file are supposed to be exactly the timestamp of the commit you supplied (master). What is the timestamp of that commit, and is it equal to that timestamp 2014-10-29 13:09:52 which is in the future? Display the raw value with for example git log -n1 --format=format:%at,%ct master.
    – Celada
    Oct 29, 2014 at 15:39
  • Yep, that's it - the commit was at that time.
    – l0b0
    Oct 29, 2014 at 20:48
  • @Celada I suggest writing an answer. Oct 29, 2014 at 21:50
  • Make sure you don't have clock skew between commits fetched from a different machine, and make sure your timezones are correct.
    – o11c
    Oct 29, 2014 at 23:05
  • @o11c I agree that the culprit here is likely clock skew. However, timezones don't need to be correct. When tar is reporting timestamps in the future, it's comparing UTC time to UTC time, so timezones don't enter into it.
    – Celada
    Oct 30, 2014 at 15:10

1 Answer 1


When you give a commit ID or tag ID (or branch name, as you've done here) to git archive, the commit time as recorded in the referenced commit object is used as the modification time of each file in the archive.

It looks like the latest commit on master was at 2014-10-29 13:09:52, which must have been in the future relative to the moment when you ran git archive. Perhaps that commit was fetched from a remote repository with an incorrect clock, or the local clock is incorrect?


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .