-
Notifications
You must be signed in to change notification settings - Fork 152
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
straight-freeze-versions + straight-thaw-versions is not no-op #294
Comments
I just stepped through the freeze process, and it looks like EDIT: OK, I think I see it: |
Oh. Yes, that is the intended behavior, except that it causes this horrible effect because #66 has not been fixed yet. I think that #66 is the correct way to address this problem—you do want to make sure that the default branch is checked out (otherwise how can you be sure that the commit will be accessible when the configuration is cloned on another machine?) but of course |
Ah, that makes a ton of sense - I think resetting the branch to the previously checked-out rev would be quite reasonable (if that rev was an ancestor of the remote's pushed branch). |
This should address radian-software#294: When thawing, we no longer leave detached heads lying around, so freezing the repo will be much more likely to be a high-touch operation. Also, this should leave the repos that we *do* have in a much nicer state for people to work on.
This should address radian-software#294: When thawing, we no longer leave detached heads lying around, so freezing the repo will be much more likely to be a high-touch operation. Also, this should leave the repos that we *do* have in a much nicer state for people to work on.
* New function straight-vc-commit-present-p: check if a SHA is fetched This function should allow us to detect if a "git fetch" is necessary upon thawing the repo. * Automatically fetch the repo when the thawed-to commit is missing This should address #58: If we're unable to find the commit locally, the easiest way to get it is probably to fetch it. * Normalize repos when thawing Since we're already going to munge the repo state, we might as well return it to the master branch and thus get it to a place where the fetch can do something reasonable. * Instead of decapitating via checkout, reset the HEAD ref This should address #294: When thawing, we no longer leave detached heads lying around, so freezing the repo will be much more likely to be a high-touch operation. Also, this should leave the repos that we *do* have in a much nicer state for people to work on. * Remove note about running fetch before thawing. With the auto-fetching behavior, I believe this should be unnecessary now. * Adjust straight-vc-check-out-commit to normalize the repo This requires the interface for the function to change: Previously it took just the local-repo, now it takes the whole recipe (because that's what normalization uses).
This should be fixed by #375. |
* New function straight-vc-commit-present-p: check if a SHA is fetched This function should allow us to detect if a "git fetch" is necessary upon thawing the repo. * Automatically fetch the repo when the thawed-to commit is missing This should address radian-software#58: If we're unable to find the commit locally, the easiest way to get it is probably to fetch it. * Normalize repos when thawing Since we're already going to munge the repo state, we might as well return it to the master branch and thus get it to a place where the fetch can do something reasonable. * Instead of decapitating via checkout, reset the HEAD ref This should address radian-software#294: When thawing, we no longer leave detached heads lying around, so freezing the repo will be much more likely to be a high-touch operation. Also, this should leave the repos that we *do* have in a much nicer state for people to work on. * Remove note about running fetch before thawing. With the auto-fetching behavior, I believe this should be unnecessary now. * Adjust straight-vc-check-out-commit to normalize the repo This requires the interface for the function to change: Previously it took just the local-repo, now it takes the whole recipe (because that's what normalization uses).
As suggested in #292 (comment), I made a reproducer repo for the issue I'm seeing: https://github.com/antifuchs/straight.el-repro-case-1 - it's an init file pulling in ace-window, and a lock file locking that to an older version.
To reproduce:
emacs -Q init.el
C-M-x
to evaluate the init file (this will bootstrap straight, so it's going to take a while)M-x straight-thaw-versions
M-x straight-freeze-versions
git diff
On my machine,
git diff
says that theace-window
version changed to the latest. I'd expect there to be no differences. This also reproduces for me if I restart emacs between steps 4 and 5.I'm testing this on
GNU Emacs 26.1 (build 1, x86_64-apple-darwin13.4.0, Carbon Version 157 AppKit 1265.21) of 2018-04-15
- the latest bottle from https://github.com/railwaycat/homebrew-emacsmacportThe text was updated successfully, but these errors were encountered: