Return to Question

Git by default does not set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the pushed files.

Doesn't it make sense for the file's modification date to be set to the value of the last commit (remote or local), rather than it leaving it the same as the date it was fetched from the server?

Git stores the last modification time for each file, based on its commit history. Why doesn't Git touch each file to their last commit time when the files are pulled from the remote repository?

I know it's possible to modify the config for Git to achieve something like this, but what I'm asking is why Git doesn't set the file time to the time recorded in the commit history by default.

If there is a particular reason why Git doesn't do this on default (other than it was a feature that nobody think would be useful), I'm interested to know about the decision against implementing this.

Git by default does not set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the pushed files.

Doesn't it make sense for the file's modification date to be set to the value of the last commit (remote or local), rather than it leaving it the same as the date it was fetched from the server?

Git stores the last modification time for each file, based on its commit history. Why doesn't Git touch each file to their last commit time when the files are pulled from the remote repository?

I know it's possible to configure Git to achieve something like this, and to restore file times, but what I'm asking is why Git doesn't set the file time to the time recorded in the commit history by default.

If there is a particular reason why Git doesn't do this on default (other than it was a feature that nobody think would be useful), I'm interested to know about the decision against implementing this.

Git by default lacks the logic to set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the origin, and IMO this is a really annoying behavior.

Doesn't it make sense for the file to have a modification date of the last commit (remote or local), rather than it having the last time it was fetched from the server?

GitHub keeps the last commit time for each file, based on their history. Why doesn't Git touch each file to their last commit time when the files are pulled from the server?

I know it's possible to modify the config for Git to achieve something like this, but what I'm asking is why Git doesn't set the file time to the time recorded in the commit history by default.

If there is a particular reason why Git doesn't do this on default (other than it was a feature that no one didn't think of it useful to actually implement it), I'm interested to know about the decision against implementing this.

Git by default does not set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the pushed files.

Doesn't it make sense for the file's modification date to be set to the value of the last commit (remote or local), rather than it leaving it the same as the date it was fetched from the server?

Git stores the last modification time for each file, based on its commit history. Why doesn't Git touch each file to their last commit time when the files are pulled from the remote repository?

I know it's possible to modify the config for Git to achieve something like this, but what I'm asking is why Git doesn't set the file time to the time recorded in the commit history by default.

If there is a particular reason why Git doesn't do this on default (other than it was a feature that nobody think would be useful), I'm interested to know about the decision against implementing this.

Git by default lacks the logic to set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the origin, and IMO this is a really annoying behavior.

Doesn't it make sense for the file to have a modification date of the last commit (remote or local), rather than it having the last time it was fetched from the server?

GitHub keeps the last commit time for each file, based on their history. Why doesn't Git touch each file to their last commit time when the files are pulled from the server?

If there is a particular reason why Git doesn't do this when (other than it was a feature that no one didn't think of it useful to actually implement it), I'm interested to know about the decision against implementing this.

Git by default lacks the logic to set the file-time accordingly when the files are synced with the origin. It just ignores the file-time of the origin, and IMO this is a really annoying behavior.

Doesn't it make sense for the file to have a modification date of the last commit (remote or local), rather than it having the last time it was fetched from the server?

GitHub keeps the last commit time for each file, based on their history. Why doesn't Git touch each file to their last commit time when the files are pulled from the server?

I know it's possible to modify the config for Git to achieve something like this, but what I'm asking is why Git doesn't set the file time to the time recorded in the commit history by default.

If there is a particular reason why Git doesn't do this on default (other than it was a feature that no one didn't think of it useful to actually implement it), I'm interested to know about the decision against implementing this.