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

Comments

Projects
None yet
4 participants
@hesselink
Contributor

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

This comment has been minimized.

Member

chrisdone commented Jul 3, 2015

👍

1 similar comment
@zudov

This comment has been minimized.

Contributor

zudov commented Jul 3, 2015

👍

@snoyberg

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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