{"thread":{"id":"48341","subject":"Git enhancement request - checkout (clone) set modified dates to commit date","startedAt":"2018-04-22T17:43:14Z","lastAt":"2018-04-23T03:32:38Z","messageCount":6,"participants":["Andrew Wolfe","brian m. carlson","Kevin Daudt","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"345402","messageId":"585A3A2E-7DA6-4718-BF85-2D17AAAF3EF5@schemaczar.com","threadId":"48341","inReplyTo":null,"subject":"Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"Andrew Wolfe","fromEmail":"andrew@schemaczar.com","sentAt":"2018-04-22T17:18:10Z","receivedAt":"2018-04-22T17:43:14Z","isPatch":false,"sender":{"key":"andrew@schemaczar.com","avatar":"https://gravatar.com/avatar/00ac9195ab188ef4ea5080fe2421c4c7a3e39024435cf9f8bb3a9320a3cd0246?d=mp&s=160"},"body":"Hello,\n\nthere are several timestamps in the lifecycle of a modification to a file in Git:\n\n\t• file write timestamp\n\t• git add timestamp\n\t• git commit timestamp\n\t• git push timestamp\n\t• git merge timestamp\n\t• git checkout timestamp\n\nRight now when I check out/clone a repository, all the files have the checkout timestamp as\n\n\t• ctime - creation time for the file\n\t• mtime - modification time for the file\n\t• atime - las access time for the file\n\nNot 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.\n\nI 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.\n\nWhen 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.\n\nSincere regards,\n\nAndrew Wolfe\n\n\n"},{"id":"345404","messageId":"20180422180912.GK14631@genre.crustytoothpaste.net","threadId":"48341","inReplyTo":"585A3A2E-7DA6-4718-BF85-2D17AAAF3EF5@schemaczar.com","subject":"Re: Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-04-22T18:09:12Z","receivedAt":"2018-04-22T18:09:21Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote:\n> 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.\n\nThe reason Git doesn't do this is pretty simple: make and various other\ntools do rebuilds depending on timestamps.\n\nIf I create a branch off master and make some commits, then switch back\nto master, I will want the changed files to have their timestamps\nupdated to be newer so that a make on master will rebuild dependencies\nbased on those files.  If I set the files to the commit timestamp, those\nfiles would be set to the timestamp of master, which is older than my\nnew branch, and make wouldn't work properly.\n\nThere are some cases where people want the behavior you requested, such\nas for reproducible builds, and in such cases, you can use a\npost-checkout hook to set timestamps with touch.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"345408","messageId":"1FCE6958-FC75-4A9B-88A3-05AE991815E4@schemaczar.com","threadId":"48341","inReplyTo":"20180422180912.GK14631@genre.crustytoothpaste.net","subject":"Re: Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"Andrew Wolfe","fromEmail":"andrew@schemaczar.com","sentAt":"2018-04-22T19:01:10Z","receivedAt":"2018-04-22T19:50:31Z","isPatch":false,"sender":{"key":"andrew@schemaczar.com","avatar":"https://gravatar.com/avatar/00ac9195ab188ef4ea5080fe2421c4c7a3e39024435cf9f8bb3a9320a3cd0246?d=mp&s=160"},"body":"Hi Brian,\n\nNot 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.\n\nHowever, 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.\n\nIf you're doing a merge, it will entail a commit and, again, the modified files will be newer.\n\nI don't think your use case breaks my proposal.\n\n- Andrew Wolfe\n\n> On Apr 22, 2018, at 2:09 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:\n> \n> On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote:\n>> 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.\n> \n> The reason Git doesn't do this is pretty simple: make and various other\n> tools do rebuilds depending on timestamps.\n> \n> If I create a branch off master and make some commits, then switch back\n> to master, I will want the changed files to have their timestamps\n> updated to be newer so that a make on master will rebuild dependencies\n> based on those files.  If I set the files to the commit timestamp, those\n> files would be set to the timestamp of master, which is older than my\n> new branch, and make wouldn't work properly.\n> \n> There are some cases where people want the behavior you requested, such\n> as for reproducible builds, and in such cases, you can use a\n> post-checkout hook to set timestamps with touch.\n> -- \n> brian m. carlson: Houston, Texas, US\n> OpenPGP: https://keybase.io/bk2204\n\n"},{"id":"345409","messageId":"20180422195923.GA10082@alpha","threadId":"48341","inReplyTo":"1FCE6958-FC75-4A9B-88A3-05AE991815E4@schemaczar.com","subject":"Re: Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2018-04-22T19:59:24Z","receivedAt":"2018-04-22T20:08:30Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:\n> Hi Brian,\n> \n> Not completely sure what you're saying.  If the files on master are\n> not changed, the changed files' commit timestamps will be older than\n> the branch commit timestamps.\n> \n> However, if I check out master after committing to a branch, the\n> modifications will necessarily disappear because they haven't been\n> committed to master.  Instead, under my proposal, each will get the\n> timestamp of its prior commit.\n> \n\nSay I build the project while on a certain branch. Then I checkout a\ndifferent branch and build again. You would expect that the targets of\nevery source file that have changed are rebuilt.\n\nWhen you would restore the timestamp back to the commit timestamp, the\ntimestamp will be older then the target, and make will not rebuild it,\nleaving you with outdated build targets.\n"},{"id":"345436","messageId":"3BCD276C-BC6B-47BD-A27C-05D7C0C07280@schemaczar.com","threadId":"48341","inReplyTo":"20180422195923.GA10082@alpha","subject":"Re: Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"Andrew Wolfe","fromEmail":"andrew@schemaczar.com","sentAt":"2018-04-23T00:23:37Z","receivedAt":"2018-04-23T00:44:25Z","isPatch":false,"sender":{"key":"andrew@schemaczar.com","avatar":"https://gravatar.com/avatar/00ac9195ab188ef4ea5080fe2421c4c7a3e39024435cf9f8bb3a9320a3cd0246?d=mp&s=160"},"body":"Kevin, thanks for your feedback.\n\nYou 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.\n\nOn 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.\n\nWhen 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.\n\n- Andrew\n\n> On Apr 22, 2018, at 3:59 PM, Kevin Daudt <me@ikke.info> wrote:\n> \n> On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:\n>> Hi Brian,\n>> \n>> Not completely sure what you're saying.  If the files on master are\n>> not changed, the changed files' commit timestamps will be older than\n>> the branch commit timestamps.\n>> \n>> However, if I check out master after committing to a branch, the\n>> modifications will necessarily disappear because they haven't been\n>> committed to master.  Instead, under my proposal, each will get the\n>> timestamp of its prior commit.\n>> \n> \n> Say I build the project while on a certain branch. Then I checkout a\n> different branch and build again. You would expect that the targets of\n> every source file that have changed are rebuilt.\n> \n> When you would restore the timestamp back to the commit timestamp, the\n> timestamp will be older then the target, and make will not rebuild it,\n> leaving you with outdated build targets.\n\n"},{"id":"345442","messageId":"CA+P7+xr99UyLVOrRYxRV=s8o5eJXzvOxZy5w51_FY_BYOue=VA@mail.gmail.com","threadId":"48341","inReplyTo":"3BCD276C-BC6B-47BD-A27C-05D7C0C07280@schemaczar.com","subject":"Re: Git enhancement request - checkout (clone) set modified dates to commit date","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-04-23T03:32:13Z","receivedAt":"2018-04-23T03:32:38Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe <andrew@schemaczar.com> wrote:\n> Kevin, thanks for your feedback.\n>\n> 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.\n>\n> 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.\n\nNot every build has this problem, and certainly I think some of the\nmost common build software would not (Make). It's fairly easy to fix\nthis by using a git hook to update files post checkout (you can look\nup the timestamp of each file's commit time, or any other time and use\ntouch to do this yourself).\n\nThanks,\nJake\n"}]}