Bitbucket Pull Requests 'Checkout Source Branch' and 'Edit In File' fail to add remote with fatal git command error

[Chris Golden]

Bitbucket Pull Requests 'Checkout Source Branch' and 'Edit This File' fail to add remote with fatal git command error:

fatal: '~USERNAME/reponame' is not a valid remote name

Reviewing the code it appears that the raw value of 'pr.data.source.repo.fullName' is being passed into the name parameter of scm.addRemote in ‘src/webviews/pullRequestWebview.ts’ and 'src/views/gitActions.ts'

We are using:
Bitbucket Server 6.6

Clients:
Mac OS X, Linux and Windows
VSCode 1.44.2
Atlassian VS Code Extension version 2.5.1
git 2.26

Is there a suggested workaround or a pending code fix for this behavior?

[Pramod Busam]

@Chris Golden It looks like the actions are failing for a Bitbucket Server personal repository. Could you check if it works for a regular repo (where there's no ~ before the username in the URL)?

[Pramod Busam]

Linked to VSCODE-1106

[Chris Golden]

I was able to come up with a hack for this, but I don't believe it is advisable or at all tenable long term and should be just an example of the issues where this is not working with the current parameters passed to scm.addRemote

From what I can tell the current scm.addRemote is only receiving the correct arguments for workspace/project repo’s and that an implementation for pull request branches in user personal repo’s is not implemented.

below are the steps you can use as a hack to workaround and verify the missing functionality and manually add the remotes with the remote name the atlascode extension is expecting and a working uri for ssh based personal user repos. Note: this requires that the user clicking the ‘Checkout Source Branch’ have read access to the personal repo of the the branch is stored in.

1.click the ‘Checkout Source Branch’ button on a Pull request while watching the Output terminal for the Git scm
you should see an error message similar to the below:

git config --local remote.~USERNAME/reponame.url 
git remote add ~USERNAME/reponame ssh://[e-mail]:7999/users/USERNAME/repos/reponame fatal: '~USERNAME/reponame' is not a valid remote name

2. login to Bitbucket and browse to the users fork of the repo and copy the clone uri

3. login to a terminal where you have a cloned copy of the main version of the repo from your project. Run the below commands replacing ‘CORRECT_REPO_URI’ with the clone path you copied from step 2:

git remote add username/reponame CORRECT_REPO_URI
git config --local --edit

4. In the editor locate the newly added remote definition (usually at the bottom of the file) and edit it:
edit [remote "username/reponame"] to be [remote "~USERNAME/reponame"] and then save and exit the file
Note: git officially does not support ‘~' in the remote names when creating remotes, but manually editing after the fact like this appears to allow fetch and checkout of the branches with these remote names. YMMV for commiting and pushing as I have not tested that.

5. run the git config --local remote.~USERNAME/reponame.url found in step 1 again to verify that the rmote exists and the URI is correct.

6. run a git fetch ~USERNAME/reponame to verify that you can fetch and that the git uri works.

7. now navigate back to the original pull request.
click ‘Checkout Source Branch’ and verify that your repo switches to the correct source branch with a git status in your terminal
checkout master or your default branch again
navigate to one of the files in the pull request in vs code
right click on the file in the diff view and choose ‘Edit This File’. You should get a new editor panel with the file ready to be edited and your git should be checked out once more to the source branch from the pull request.

Again, these steps are just a hack to demonstrate that it is possible to get this to work, it just appears that the orchestration in the atlascode extension does not have an implementation to do so where scm.Addremote is ultimately called.

‌

[Chris Golden]

Thank you for the reply

Yes, I can confirm that a regular project repo pull request works.

My previous post a few moments ago details further investigation I have been able to perform to verify a way to get this to work and that it appears the input parameters passed in for scm.addRemote are incorrect for personal repos.

[Pramod Busam]

@Chris Golden Thanks for providing the detailed steps for reproducing and fixing the issue. That's definitely helpful. I think we should be able to replace the ~ with a custom constant string to fix the issue.

[Chris Golden]

Thanks for the update.

Yes a fix to handle the '~' in Bitbucket Server sounds good.

One Additional note though, as it may not have been clear in my repro steps for the blocking behavior.

The URI for the git repo that atlascode is trying to create the remote using is appearing as the below in the git scm output:

ssh://[e-mail]:7999/users/USERNAME/repos/reponame

But the correct URI for Bitbucket server is:

ssh://[e-mail]:7999/~USERNAME/reponame.git

A change of the URI lookup and/or a rewrite of the URI string may be required.

Also as you had also asked about non user repos before, our project repo URLs are like the below:

ssh://[e-mail]/PROJECT/reponame.git

‌

[Chris Golden]

Just wanted to update from my end.

We are still seeing issues with the scm.AddRemote logic for the 'Checkout Source Branch' and 'Edit In File'  options of atlascode.

Changes we have made to our environment to see if they have any change in behavior:

• We have updated to Bitbucket 7.2
• We have tried using atlascode with “HTTP(S) SCM hosting” disabled in the Bitbucket server settings.
• Updated atlascode to the latest 2.6.0 release

It looks like the logic to determine what the URI should be (ssh or https) is not correct and is not using the correct bitBucket server style path for ssh (it’s using the https scm one).

I don’t see a setting anywhere in the atlascode addon that would allow users to prefer the https or ssh scm URI’s. Maybe that should be added as well?

Also, thank you for your continued work on improving this addon the fixes in 2.6.0 help quite a bit.

‌

[Pramod Busam]

Fixed in version 2.6.2. Please re-open if the problem persists.