Git enhancement request - checkout (clone) set modified dates to commit date

Hello,

there are several timestamps in the lifecycle of a modification to a file in Git:

	• file write timestamp
	• git add timestamp
	• git commit timestamp
	• git push timestamp
	• git merge timestamp
	• git checkout timestamp

Right now when I check out/clone a repository, all the files have the checkout timestamp as

	• ctime - creation time for the file
	• mtime - modification time for the file
	• atime - las access time for the file

Not only does this force more work for timestamp-based build programs, it also deprives me, as a developer, of a visual 'file blame' that could be very useful in spotting changes without having to do git log over and over.

I would like to propose that the checkout process set the create and modification times of a file to the timestamp at which a file was committed.

When repository servers have different clocks - which is normal - each clone/merge/push should record the time offset.  Each timestamp on each commit should be corrected to the repository's specific time, and that should be a marking on the history.

Sincere regards,

Andrew Wolfe

On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote:

The reason Git doesn't do this is pretty simple: make and various other tools do rebuilds depending on timestamps.

If I create a branch off master and make some commits, then switch back to master, I will want the changed files to have their timestamps updated to be newer so that a make on master will rebuild dependencies based on those files. If I set the files to the commit timestamp, those files would be set to the timestamp of master, which is older than my new branch, and make wouldn't work properly.

There are some cases where people want the behavior you requested, such as for reproducible builds, and in such cases, you can use a post-checkout hook to set timestamps with touch.

Hi Brian,

Not completely sure what you're saying.  If the files on master are not changed, the changed files' commit timestamps will be older than the branch commit timestamps.

However, if I check out master after committing to a branch, the modifications will necessarily disappear because they haven't been committed to master.  Instead, under my proposal, each will get the timestamp of its prior commit.

If you're doing a merge, it will entail a commit and, again, the modified files will be newer.

I don't think your use case breaks my proposal.

- Andrew Wolfe

On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:

Say I build the project while on a certain branch. Then I checkout a different branch and build again. You would expect that the targets of every source file that have changed are rebuilt.

When you would restore the timestamp back to the commit timestamp, the timestamp will be older then the target, and make will not rebuild it, leaving you with outdated build targets.

Kevin, thanks for your feedback.

You have a reasonable point, because usually you don't put the outputs of a build into version control, but the build script checks them for being current.

On the other hand, when you change branches, your existing output directories are worthless problems anyway — even if you have all the interdependencies correct.  Because of this, I'm inclined to consider this use case as intrinsically hazardous.  When I do a checkout, I always want to purge all the intermediate and end targets regardless.

When doing a build, it's often useful to put the current commit/branch into the output directories as documentation; I usually do this in my build scripts.  This also makes it simple to detect when the branch is changed and clean the outputs.

- Andrew

On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe <andrew@schemaczar.com> wrote:

Not every build has this problem, and certainly I think some of the most common build software would not (Make). It's fairly easy to fix this by using a git hook to update files post checkout (you can look up the timestamp of each file's commit time, or any other time and use touch to do this yourself).

Thanks, Jake