Are you doing this on the client-side? To me this sounds more like a server-side task which would be triggered by some post-receive hook. Are all three steps done at the same time? If so, when exactly?

The notification was not yet triggered for "visualstudio.com" domains. This is fixed now in build 17079.

> repos where the origin URL is specified as https://[org].visualstudio.com don't show the Azure logo in SmartGit.

That's unexpected. Such URLs should work since build 17074 and "DefaultCollection" should be handled correctly since build 17078. @hrant has confirmed this -- please see our discussion above. Are you referring to exactly this kind of URLs or am I misunderstanding?

Thanks! Build 17078 should now correctly handle "DefaultCollection".

Thanks, I understand now. Paging ($top,$skip) isn't supported for that API. I have uploaded build 17075 which should fix this problem. This most likely also explains the out-of-memory error: SmartGit reads and caches an infinite amount of JSON objects and finally runs out-of-memory.

@hrant and @Martillo, again thanks for your testing and feedback. I have now uploaded build 17074 which comes with following changes/fixes:

• Pull Request: Open in Web Browser
• Fix Commit view Open link
• Support for .visualstudio.com URLs (hopefully)
• Fix possible internal error related to comment IDs
• Retract/Reject Pull Request is now both "Abandon Pull Request"; in all cases, for all Hosting Providers both functions are about "cancelling" a pull request, not about reviewing where one would Approve/Reject a pull request
  
  

When exactly did this happen?

For my small test organization the paging logic works. Is it possible that your organization has really many repositories and SmartGit is not actually stuck but it only takes a long time to complete? When comparing:

https://dev.azure.com/org1/_apis/git/repositories?api-version=6.1-preview.1&$top=50&$skip=0

and:

https://dev.azure.com/org2/_apis/git/repositories?api-version=6.1-preview.1&$top=50&$skip=50

in your browser, are results different?

> I tested connecting using an OAuth token when "Allow Third-party Application access via OAuth" was turned off for the org in Azure DevOps (see screenshot) and got an HTTP 401 response, so it would helpful to add some instructional text in the dialog box to note that this needs to be turned on in the org.

Thanks for this hint! Usually we collect possible problems with Hosting Provider setups in our docs, hence I have added this information there: https://www.syntevo.com/doc/display/SG/Azure+DevOps

> Also, I had real problems creating an OAuth token for an org where I authenticate with a different MS account than the one I'm logged into my Windows workstation with, so I gave up and used a PAT instead.

So you can't simply switch accounts in your browser? This works fine for e.g. GitHub/Bitbucket, but I understand that for Azure authentication maybe somehow be tied to your workstation login. In this case, I agree, PATs may be the best choice.

> Since authenticating with OAuth tokens for multiple MS accounts could be problematic, you might get fewer support request from users if you encourage PATs over OAuth.

I'm wondering how common it is with Azure that one user has multiple accounts? Why do you as a single person have multiple accounts? Note that you wrote about "multiple Azure DevOps instances" which is something different: there must be a way to switch between them in the browser and then OAuth should work out-of-the-box.

> For PATs, it would also be helpful to add some text on the Azure DevOps Configure Hosting Provider dialog to explain that a PAT only needs Code Read/Write permissions but access to all accessible orgs.

I have checked related code, but it can only distinguish between automatic generated tokens and manually entered tokens. After the token has been confirmed such an info could be displayed. But especially during setup while the user may type/paste anything into the Token text field, I can't tell whether this is a PAT or not. Hence, providing a reliable text here is a bit tricky.

> BTW , by "Retract Pull Request" do you mean "Abandon"?

SmartGit is using "Retract" for outgoing pull requests. For all Hosting Providers, the underlying commands which will be executed are identical to Rejecting a pull request. Hence, for the next build, I have switched from "Retract" to "Reject", except for Azure DevOps which will use "Abandon" instead of "Retract"/"Reject".

I'm not planning to support PATs which are limited to certain organizations. Note that PATs are anyway only a workaround in case your have troubles with OAuth authentication (usually you shouldn't have). Such limited PATs would make several code parts more complicated. For example, already "_apis/profile/profiles/me" fails.

If you have different user accounts (=emails), that should be supported by setting up one Azure DevOps Hosting Provider per account.