-
Notifications
You must be signed in to change notification settings - Fork 63
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
scalar upgrade fails with "Could not find Git installer in the latest release" #351
Comments
Hi @rainersigwald. We are working on an improved upgrade story, and plan to remove the Cc: @mjcheetham |
I realized what the problem is and will work on a fix tomorrow. The problem is the difference here: On VFS for Git, we only support Windows so all assets are available separately: But on Scalar, we support Windows and Mac, so our installers look completely different: The command |
…r Git Scalar was created by forking the VFS for Git codebase, deleting a bunch of code, then renaming a bunch of files. It has since diverged significantly through many refactors. One thing that has _never worked_ is the `scalar upgrade` verb when using GitHub as the source. The reason is that we package our releases differently than VFS for Git does, so the upgrader fails to find the Git installer and Scalar installer (instead, we have two `.zip` files, one for each platform). Since we are moving to another system for the typical upgrade pattern, we should just delete the GitHub upgrader. The `scalar upgrade` verb will remain for the NuGet feed, when configured. This resolves #351. An issue was found in VFS for Git where the service would restart constantly when checking for an upgrade. The root cause was a problematic `Environment.Exit()` call. See microsoft/VFSForGit#1668 for an equivalent change. Another annoying thing is the verbose output during `scalar clone` that repeats the given options. In the case of a non-GVFS protocol clone, some of these just don't make sense. Delete this output for clarity. Finally, `scalar clone` failed miserably when using a non-standard URL such as `file://`. Fix that by doing some URL scanning in advance. If the URL does not start with `http://` or `https://`, we will not even try the GVFS protocol and will move on to a native Git clone. We also avoid any protocol prefix (`X://`) that is not `http://`, `https://` or `ssh://`. For SSH, the protocol prefix is not required, so we do not require a protocol prefix. Resolves #378. Since this is a grab-bag of things, please review commit-by-commit. For the GitHub upgrader removal, consider ignoring whitespace changes.
from the other window
from that log
(that was under the debugger, the duration is bogus)
In the debugger, I can see:
And indeed that seems to match the release assets. But isn't git packed into the .zip?
The text was updated successfully, but these errors were encountered: