21

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.

Improve this question
1

2 Answers 2

Reset to default
32

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.

Improve this answer
3
  • 2
    That sounds very plausible to me. Still, I'd like to see some quote showing that this was indeed the reason for the original design choice, not just a result of it. Do you have a source?
    – Daniel Wolf
    Commented Sep 20, 2021 at 6:45
  • 5
    @Dan git.wiki.kernel.org/index.php/…
    – CrazyPyro
    Commented Jul 13, 2022 at 18:01
  • I'd even add that there are subtler "build" systems that depend upon file modification times. The CPython runtime prefers bytecode files to source files, and only updates those when the source file is newer than the bytecode file. If git checkout changed the file modification time to the commit time in an installed package, then python would only ever be able to import the most recently committed version, ignoring whatever was currently checked out.
    – Jake Stevens-Haas
    Commented May 23 at 17:59
0

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.

Improve this answer
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
    Commented Jun 7, 2017 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
    Commented Jun 7, 2017 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
    Commented Jun 17, 2017 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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