tags:

views:

124

answers:

2

I understand the default git behaviour of updating the modification time every time it changes a file, but there are times when I want to restore a file's original modification time.

Is there a way I can tell git to do this?

(As an example, when working on a large project, I made some changes to configure.ac, found out that autotools doesn't work on my system, and wanted to restore configure.ac's to its original contents and modification time so that make doesn't try to update configure with my broken autotools).

+4  A: 

Git does not do this. Like your linked FAQ says, it would break using timestamp-based dependency analysis tools like make.

Think about what would happen if old time stamps were applied to files checked out from ‘old’ commits:

  • make from a clean directory works fine
  • checkout an older branch/tag/commit (the files would have timestamps older than the build products now!)
  • make now does nothing because all the build products are newer than their dependencies

But, if you really want it, all the information is there. You could write your own tool to do it.

In your case, just use something like touch -t configure configure.ac to reset the modification time of only configure.ac, (or bring configure forward in time with touch configure).


Actually this is an easy “exercise for the reader” if you want to practice reading C code. The function that changes timestamps is utime or utimes. Search the code for uses of those functions (hint: git grep utime in a git.git clone). If there are some uses, analyze the code paths to find out when it updates timestamps.

Chris Johnsen
I agree, it's a good default. I was just hoping there was a flag or command for non-default behaviour. I suppose for now I'll put off playing with git's plumbing in favor of just using `touch` to get the job done.
rampion
It would be nice if `git archive` could restore the original file modification time of every file in the archive, but unfortunately, it sets all the modification times to either the current time or the timestamp of the selected commit.
Derek Mahar
+1  A: 

I believe the 'proper' fix is to actually compare the SHA1 of each input file to see if it's changed from the last build.

This is a lot of work, however I have started a project to try and create a proof of concept (still very early stage). As well as identifying the correct build steps it's also designed to create an audit list of input files for later forensics.

See http://github.com/alecthegeek/gitbuilding -- it's based on something similar I did a few years ago with SVN

Alec the Geek
that'd be nice for future projects :)
rampion