Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use file hashes instead of modification time for tracking changes #502

Closed
hesselink opened this issue Jul 3, 2015 · 8 comments
Closed

Use file hashes instead of modification time for tracking changes #502

hesselink opened this issue Jul 3, 2015 · 8 comments
Assignees
Milestone

Comments

@hesselink
Copy link
Contributor

@hesselink hesselink commented Jul 3, 2015

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
Copy link
Member

@chrisdone chrisdone commented Jul 3, 2015

👍

1 similar comment
@zudov
Copy link
Contributor

@zudov zudov commented Jul 3, 2015

👍

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jul 3, 2015

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.

@snoyberg snoyberg self-assigned this Jul 3, 2015
@snoyberg snoyberg added this to the 0.2.0.0 milestone Jul 3, 2015
@hesselink
Copy link
Contributor Author

@hesselink hesselink commented Jul 3, 2015

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
Copy link
Contributor

@snoyberg snoyberg commented Jul 3, 2015

--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 added a commit that referenced this issue Jul 3, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jul 3, 2015

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
Copy link
Contributor Author

@hesselink hesselink commented Jul 3, 2015

@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
Copy link
Contributor

@snoyberg snoyberg commented Jul 3, 2015

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.

@snoyberg snoyberg closed this Jul 3, 2015
@snoyberg snoyberg removed the in progress label Jul 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants