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

Changing download type of git resource breaks resource updating #73

Closed
apjanke opened this issue Apr 12, 2016 · 5 comments
Closed

Changing download type of git resource breaks resource updating #73

apjanke opened this issue Apr 12, 2016 · 5 comments
Labels
help wanted We want help addressing this

Comments

@apjanke
Copy link
Contributor

apjanke commented Apr 12, 2016

Discovered in Homebrew/homebrew-core#26.

If you have a git:// resource which then converts to a https:// resource with :using => :git, updating that cached git resource may break if you're stuck with "dumb" transport.

==> Cloning https://git.universe-factory.net/fastd/ Updating /Library/Caches/Homebrew/fastd--git fatal: dumb http transport does not support --depth Error: Failed to download resource "fastd" Failure while executing: git fetch -q origin --unshallow

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:

rm -rf $(brew --cache)/fastd*           # to start fresh with this resource in "before" state
brew tap --full homebrew/core         # to make sure your repo is unshallow
cd $(brew --repo homebrew/core)
git checkout 4f01edd92 2>/dev/null           # to get before the transport change
brew fetch --HEAD fastd
git checkout master
brew fetch --HEAD fastd         # this will fail

On my 10.9.5 box with a fresh Homebrew install, I get:

[/usr/local/Library/Taps/homebrew/homebrew-core on ⇄ master]
$ gco 4f01edd92cff700e95eac5362583e76c003615c2 2>/dev/null
[/usr/local/Library/Taps/homebrew/homebrew-core on ⇄ 4f01edd]
$ brew fetch --HEAD fastd
==> Cloning git://git.universe-factory.net/fastd/
Cloning into '/Library/Caches/Homebrew/fastd--git'...
remote: Counting objects: 214, done.
remote: Compressing objects: 100% (208/208), done.
remote: Total 214 (delta 48), reused 61 (delta 1)
Receiving objects: 100% (214/214), 267.95 KiB | 164.00 KiB/s, done.
Resolving deltas: 100% (48/48), done.
Checking connectivity... done.
==> Checking out branch master
[/usr/local/Library/Taps/homebrew/homebrew-core on ⇄ 4f01edd]
$ gco master
Previous HEAD position was 4f01edd... googler 2.1 (new formula)
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
[/usr/local/Library/Taps/homebrew/homebrew-core on ⇄ master]
$ brew fetch --HEAD fastd
==> Cloning https://git.universe-factory.net/fastd/
Updating /Library/Caches/Homebrew/fastd--git
fatal: dumb http transport does not support --depth
Error: Failed to download resource "fastd"
Failure while executing: git fetch -q origin --unshallow
[✘ /usr/local/Library/Taps/homebrew/homebrew-core on ⇄ master]
$
@apjanke apjanke changed the title Changing download type of git resource breaks resource update Changing download type of git resource breaks resource updating Apr 12, 2016
@MikeMcQuaid
Copy link
Member

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 fetch will always pass.

@MikeMcQuaid
Copy link
Member

@apjanke Any thoughts on this or my comment above?

@apjanke
Copy link
Contributor Author

apjanke commented May 3, 2016

Setting the remote URL sounds like a good fix; we should try that.

@MikeMcQuaid MikeMcQuaid added the help wanted We want help addressing this label Sep 4, 2016
@alyssais
Copy link
Contributor

alyssais commented Dec 31, 2016

Looks to me like the Git remote URL is already set before every update, so that won't solve the problem.

@MikeMcQuaid
Copy link
Member

Gonna close this out just because we're not getting user issues and no-one seems to want to work on it.

@Homebrew Homebrew locked and limited conversation to collaborators May 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted We want help addressing this
Projects
None yet
Development

No branches or pull requests

3 participants