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@xxxxxxxxx> 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.
