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

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

[Andrew Wolfe]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote:
> 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.

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

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

[Andrew Wolfe]

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 Apr 22, 2018, at 2:09 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> 
> On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote:
>> 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.
> 
> 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.
> -- 
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

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

[Kevin Daudt]

On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:
> 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.
> 

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.

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

[Andrew Wolfe]

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 Apr 22, 2018, at 3:59 PM, Kevin Daudt <me@ikke.info> wrote:
> 
> On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:
>> 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.
>> 
> 
> 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.

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

[Jacob Keller]

On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe <andrew@schemaczar.com> wrote:
> 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.

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