Sync GitHub context with Visual Studio (possible technologies and workflows)

[jcansdale]

A spike of this functionality can be found at #1763.

Technologies

How might information about the GitHub context get into Visual Studio?

• URL handlers
• Copy/paste buffer
• Browser windows

URL handlers

At the moment there is the option to clone a GitHub repository from the repository's homepage. This is a push model where the action is initiated from outside Visual Studio and a new process is fired up.

This uses the git-client://clone?repo= protocol, which is built into Visual Studio 2015 and 2017.

Copy/paste buffer

Offer user the option to open a repository form a URL. This is a mixed model where an action is required from inside the browser (copy URL) and inside Visual Studio (open from URL).

Browser windows

Automatically detect open browser windows and offer to sync context from inside Visual Studio. This is a pull model where the action is initiated from inside Visual Studio and the current context is changed.

Related

• [spike] Open from GitHub URL
  [spike] Open from GitHub URL #1763

• RFC for Open in Atom: A quick way to switch from github.com to Atom.
  RFC for Open in Atom atom/github#1525

[simurai]

Automatically detect open browser windows

That sounds interesting.. a bit like magic.. 😀 Although there might be privacy concerns? "Wait, is Visual Studio spying on my browsing history?"

I think I'd prefer "URL handlers" with a fallback for "Copy/paste buffer".

[drguthals]

Agreed @simurai

Something that is really really neat, but we need to be cautious about perception of our features, even if our intention is only good 😄

[jcansdale]

@simurai, @sguthals,

Although there might be privacy concerns? "Wait, is Visual Studio spying on my browsing history?"

Good point. We could be explicit about where we're getting it from. E.g "From topmost browser title" / "From clipboard URL". That way it would be super convenient, but users would understand where it's coming from.

I think I'd prefer "URL handlers" with a fallback for "Copy/paste buffer".

There's a neat trick we could do with Visual Studio's built in git-client://clone?repo=https://github.com/owner/repo URL handler and the GitHub PR page.

When a user opens Visual Studio using this URL handler, we're only given the owner and repository names. However it is possible to find the parent process and the title of that parent process. From that we can find the PR that initiated the action and take the user directly to our PR page in Visual Studio.

1. We wouldn't have to install and maintain our own URL handler
2. GitHub can detect when the git-client handler is available and only advertise this functionality user who have Visual Studio installed
3. Being able to open a PR branch in an editor makes convenient something that is otherwise a confusing hassle!

[simurai]

1. We wouldn't have to install and maintain our own URL handler
2. GitHub can detect when the git-client handler is available and only advertise this functionality user who have Visual Studio installed

Do you mean that github.com would replace open this in GitHub Desktop with open this in Visual Studio and also the URL handler from x-github-client:// to git-client://.

Or is it that when someone clicks on the open this in GitHub Desktop link and x-github-client:// is opened, Visual Studio "hijacks" that and overrides it? I think Tower is doing the hijacking, but I never got it to work properly.

[donokuda]

As mentioned previously by @sguthals and @simurai, I'd try to lean towards not being too "magical" and encourage as many explicit user actions as possible. That said, it might be possible to alleviate some of the concerns for techniques such as reading from the browser windows.

We could consider something like making the feature "opt-in" and have a disclaimer that we don't send any information about the browser anywhere. Another potential entry-point for reading the browser tabs is to have a submenu like Open from GitHub -> Open from browser -> [List of browser tab titles]

Good point. We could be explicit about where we're getting it from. E.g "From topmost browser title" / "From clipboard URL". That way it would be super convenient, but users would understand where it's coming from.

If we were to use language like "From topmost browser title" or "From clipboard," we might want to consider adding what that value exactly is (e.g., "From browser: 'PR list polish: Move comment count...'" or "From clipboard: https://github.com/github/VisualStudio/pull/1768") That would reduce the amount of times someone would need to double check what's in their clipboard or browser.

[jcansdale]

@simurai,

Do you mean that github.com would replace open this in GitHub Desktop with open this in Visual Studio and also the URL handler from x-github-client:// to git-client://.

Sorry, I wasn't very clear. There is already a URL handler called git-client:// which is installed by Visual Studio and appears on the Clone or download drop-down options when .com detects that it's installed.

The problem is we can't currently use this handler at the bottom of a GitHub PR page because there is no build it mechanism to pass the PR number. That's where looking back at the window title of the process that launched Visual Studio might come in. We could handle this situation any way we like as Visual Studio opens.

This is however a bit of a hack and there are other issues with the built in URL handler. The main one is that different versions of Visual Studio fight over which is going to one is going to handle the URL. It is common for Visual Studio developers to have multiple versions installed and invariably the wrong version is opened.

Luckily there will soon be a way to install a protocol handler when an extension is installed:
https://github.com/Microsoft/VSSDK-Extensibility-Samples/tree/master/ProtocolHandler

This would have a few advantages:

1. Only new versions of Visual Studio 2017 with GitHub for Visual Studio installed would attempt to handle the protocol
2. We could detect that the user has GitHub for Visual Studio installed not just some version of Visual Studio
3. Since we know the user has GitHub for Visual Studio installed would could make the Open GitHub for Visual Studio button really obvious! 😉

[jcansdale]

@donokuda,

We could consider something like making the feature "opt-in" and have a disclaimer that we don't send any information about the browser anywhere. Another potential entry-point for reading the browser tabs is to have a submenu like Open from GitHub -> Open from browser -> [List of browser tab titles]

I really like this idea! Open from GitHub could appear as a dynamically populated menu like the ones you find at the bottom of the File menu with any number of From clipboard: https://github.com/github/VisualStudio/pull/1768 and From browser: 'PR list polish: Move comment count...' items.

We could even populate it with local repositories that the user recently commuted from or some other heuristic we might dream up to infer significance. 😉

I'm thinking a super light-weight version of @simurai's "concertina" view - if that makes sense?