4

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.

1
18

It's because it would break every build system like make, maven, gradle, etc. that depends on file modification times to know what needs to be rebuilt. If a git checkout or a git pull pulls in commits that are older than the last executable you built, it would give those files an older timestamp. make therefore won't detect them as an updated dependency, and won't include those in a new build without doing a make clean first. This is super annoying.

There is git log for finding the last time a file was modified in version control and ls for finding the last time it was modified on your local disk, and it turns out there's good reasons for keeping those separate.

1

Honestly, i think its because the goal was to make Git as fast as possible. So instead of adding extra things the focus was (and still is) on making committing and patching as fast as possible.

However i don't think it has ever really been explicitly stated.

3
  • I understand your answer, but as Git only modifies the files that are modified on remote, does setting the time after the modification really slow down the process so noticeably to disable such feature? – David Refoua Jun 7 '17 at 23:05
  • Honestly, I'm not completely sure. I'm sure the devs had some reason they came up with when they did it. – Rhys Johns Jun 7 '17 at 23:07
  • @DRSDavidSoft -- "touch" is very fast. But writing the code to call touch is a potentially-complicated, potentially-buggy extra feature. When a system (like the earliest versions of Git) is being prototyped, it is important to minimize the number of potentially-buggy features before getting real-world feedback. And once you start getting real-world feedback, you have effectively created standard interface semantics. It think it would be impossible to change this interface's semantics in a backward-compatible way. – Jasper Jun 17 '17 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.