Obnoxious interaction of wit update with changing ssh to https

[jackkoenig]

If you use git config --global url.'https://github.com/'.insteadOf '[email protected]:, you'll get the following on wit update with v0.11.1 and master

[WARNING] Package 'chisel3' wants a different git remote origin.
Origin is currently:
  https://github.com/freechipsproject/chisel3.git
Package 'chisel3' wants origin:
  [email protected]:freechipsproject/chisel3.git
Please manually update the origin with:
  git -C /home/workspace/chisel3 \
    remote set-url origin [email protected]:freechipsproject/chisel3.git

[richardxia]

I'm not exactly sure how we'd want to handle this, since these are technically two different remotes. It's only by convention that GitHub happens to configure both its HTTP Git servers and its SSH Git servers such that you can perform the [email protected]:foo/bar.git -> https://github.com/foo/bar.git transformation and vice versa. There's no guarantee that all Git servers which happen to support both HTTP and SSH protocols will preserve this mapping.

Just as a reminder, [email protected]:foo/bar.git is more or less equivalent to the SCP command scp [email protected]:foo/bar.git, which really means "SSH into the server at github.com using the username git and grab the directory located at foo/bar.git relative to my default directory (usually the home directory)". https://github.com/foo/bar.git is more or less equivalent to "Make an HTTP request to the server at github.com and to the path at foo/bar.git". Nothing requires that the two protocols have consistent naming conventions.

[mmjconolly]

Does this warning stop forward progress?
If yes, perhaps we could have a --skip-remote-checks or --use-in-repo-remotes for people who run into this but then decide that it actually was ok to continue

[jackkoenig]

It doesn't stop forward progress, it's just annoying. There may just not be a reasonable solution other than perhaps built-in wit support for this (ie. fixing #150)