From: Andrew Wolfe Date: Mon, 23 Apr 2018 00:23:37 GMT Subject: Re: Git enhancement request - checkout (clone) set modified dates to commit date Message-ID: <3BCD276C-BC6B-47BD-A27C-05D7C0C07280@schemaczar.com> In-Reply-To: <20180422195923.GA10082@alpha> 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 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.