Let's say I created a project and pushed it to GitHub. When someone clones the project, can they see the file creation time of each file in the project?
Let's say I created a project and pushed it to GitHub. When someone clones the project, can they see the file creation time of each file in the project?
They can see the time when a file was added to the repository, via the commit date.
They cannot see the "file creation" or "file modification" timestamps of the file in your local filesystem.
$ git init
Initialized empty Git repository in /tmp/tmp.t4KdOYhQGr/.git/
$ echo bla >file.txt
$ git add file.txt
$ git commit -m 'Added a file'
[master (root-commit) 26b458c] Added a file
1 file changed, 1 insertion(+)
create mode 100644 file.txt
Let's look at the commit object:
$ git cat-file -p 26b458c
tree 80717c30ff0d58d079079d2f4d38441035093c49
author mkrieger1 <me@example.email> 1590570496 +0200
committer mkrieger1 <me@example.email> 1590570496 +0200
Added a file
It contains:
These timestamps specify when a commit was first authored, and when it was committed (can be different, e.g. in case of cherry-picking, but here it's the same).
Let's look at the tree object referenced by the commit:
$ git cat-file -p 80717c30ff0d58d079079d2f4d38441035093c49
100644 blob a7f8d9e5dcf3a68fdd2bfb727cde12029875260b file.txt
It contains a list of blob objects (only a single one in this case), with for each:
It doesn't contain any timestamps at all. Let's look at the blob object referenced by the tree:
$ git cat-file -p a7f8d9e5dcf3a68fdd2bfb727cde12029875260b
bla
It's just the bare file contents, no timestamps here, either.
The only timestamps that are stored in a Git repository are the "author" and "committer" dates in the commit objects. The tree and blob objects do not contain any timestamps.
There is no timestamp information about the files in the local filesystem contained in the Git repository.
There is no such thing as a file creation time in Git, because there are no files. The repository stores blobs and information about them. When you clone a repository or checkout a branch, that is when some files are created in your worktree and their creation date will be that moment.
Try it yourself. Clone your own remote repository and look at the creation dates of the visible files. They will all be now.
A quick test shows that, no, the file's timestamps are not preserved.
$ git init a
Initialized empty Git repository in /home/attie/stackoverflow/62039244/a/.git/
$ cd a
$ touch file
$ git add file
$ git ci -m "test"
[master (root-commit) 6cb306d] test
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
$ stat file
File: 'file'
Size: 0 Blocks: 1 IO Block: 131072 regular empty file
Device: 10000eh/1048590d Inode: 144982 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ attie) Gid: ( 1000/ attie)
Access: 2020-05-27 10:01:02.938719777 +0100
Modify: 2020-05-27 10:01:02.938719777 +0100
Change: 2020-05-27 10:01:02.938719777 +0100
Birth: -
$ cd ..
$ git clone a/.git ./b
Cloning into './b'...
done.
$ cd b
$ stat file
File: 'file'
Size: 0 Blocks: 1 IO Block: 131072 regular empty file
Device: 10000eh/1048590d Inode: 152483 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ attie) Gid: ( 1000/ attie)
Access: 2020-05-27 10:01:22.494692052 +0100
Modify: 2020-05-27 10:01:22.494692052 +0100
Change: 2020-05-27 10:01:22.494692052 +0100
Birth: -
By inspecting the commit itself, we can see that the timestamp of both the authorship and commit into the repository are stored, along with the file's type, mode and content hash... none of the underlying ctime / atime / mtime / crtime fields, or any of the rest of struct stat.
$ git cat-file -p HEAD
tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
author Attie Grande <attie@perdy.attie.co.uk> 1590570072 +0100
committer Attie Grande <attie@perdy.attie.co.uk> 1590570072 +0100
test
$ git cat-file -p df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 file
You need to be quite careful if you are dealing with the timestamps associated with a file, because in many cases it will not give you the information you might expect.
noatime or similar, then opening the file won't necessarily update this timestamp.vim), then a temporary file may be created when you save which is subsequently moved into place. In this situation all of the timestamps are updated to reflect the new file, the old file's timestamps are not preserved.