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
Show 22 quoted lines
> 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.
Andrew Wolfe <andrew@schemaczar.com>