-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Changing download type of git
resource breaks resource updating
#73
Comments
git
resource breaks resource updategit
resource breaks resource updating
The fix for this should actually be relatively easy; we should just manually set the Git remote URL each time which is a very fast local operation and means the following |
@apjanke Any thoughts on this or my comment above? |
Setting the remote URL sounds like a good fix; we should try that. |
Looks to me like the Git remote URL is already set before every update, so that won't solve the problem. |
Gonna close this out just because we're not getting user issues and no-one seems to want to work on it. |
Discovered in Homebrew/homebrew-core#26.
If you have a
git://
resource which then converts to ahttps://
resource with:using => :git
, updating that cached git resource may break if you're stuck with "dumb" transport.This looks happens because our naming scheme for caching does not include anything to differentiate the different download schemes, or handle transport differences. Deleting the cached resource and re-running the
brew
operation that uses it works fine, so it seems like initial population of this works okay, just not expanding with--unshallow
(or similar).The resource downloading logic should handle this case gracefully, either by storing resource downloads with incompatible transports under different names, or supporting an incremental update through "dumb" transport for a cached resource previously downloaded through a different transport.
To Reproduce
To reproduce:
On my 10.9.5 box with a fresh Homebrew install, I get:
The text was updated successfully, but these errors were encountered: