Use file hashes instead of modification time for tracking changes

[hesselink]

As mentioned in this email thread, switching branches, using git stash, rebasing and other operations cause lots of rebuilds, since they change the modification time of files. On the other hand, switching to a branch and back shouldn't require any rebuilds, since the sources haven't changed.

To fix this, stack could track the hash of the input files to detect changes. To make this perform, this should probably only be checked after the modification time and file size are different, as @ndmitchell mentions shake does in the email thread.

[chrisdone]

👍

[zudov]

👍

[snoyberg]

I just thought of one possible downside to this: I can picture bug reports coming in of "I ran touch foo && stack build and nothing happened" since people won't expect stack to be this smart. I don't think this should block the feature from happening, but it's something we should be aware of.

[hesselink]

If that's a concern, it could either be made an option (like it is in shake), or stack could add a flag like --force-rebuild.

[snoyberg]

--force-rebuild would end up having the same behavior most like as running stack clean first, so I'm not too concerned about it.

[snoyberg]

This is implemented in efd78d2.

@hesselink Could you give this a shot and see if it works for your use case?

@chrisdone Would you mind spot-checking the code? It's not too complicated, so I'm not that worried.

[hesselink]

@snoyberg Thanks, that's amazing! It works perfectly, there are no rebuilds after switching branches and then switching back. I also tested the 'no action' build time, and it didn't change in my (completely unscientific) tests, staying at ~3.0s.

[snoyberg]

Awesome! I'm still dissatisfied with the null builds being so long (though on large projects, that may be necessary). We have more optimizing to do in the future.

This also fixed a bug I had on a client project, so I'm quite happy with it. We'll cut a release to include this on Sunday.