Hello,

please check this PR:

fix: error fetching sha for branch name with slash in it by sushdive · Pull Request #295 · jenkins-x/go-scm · GitHub

I remember fixing this issue for go-scm

I confirm that I'm also getting an error on the /2.0/repositories/{workspace}/{repo_slug}/commit/{commit} endpoint.

https://github.com/mantisbt-plugins/source-integration/issues/376

Branch names with '/' should work with any API or path where the branch name/revision is the last part of the path. 

If you find an API where this is not the case, it can be easily fixed, relatively speaking 

@seanaty it would be appreciated if you guys could actually fix that one.

Does not work for
/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}
 response 404:

{
    "type": "error",
    "error": {
        "message": "Resource not found",
        "detail": "There is no API hosted at this URL.\n\nFor information about our API's, please refer to the documentation at: https://developer.atlassian.com/bitbucket/api/2/reference/"
    }
}

Has there been any progress with this (src)? I'm running into this and it's a real pain. The only potential solution I came up with is to do a request ahead of time to get the commit hash and use that instead of the branch name that contains a slash.

Hello all,

Sorry that this has been such a long-standing bug. I don't blame anyone for getting upset!

I've been looking into this bug and want to point out a couple of things.

1. Branch names with '/' should work with any API or path where the branch name/revision is the last part of the path. This includes, but is not limited to, the following APIs. So the API specifically mentioned on this issue is working today. I'm not sure when (I can look that up) and I'm sorry that this issue was never updated. If you find an API where this is not the case, it can be easily fixed, relatively speaking
   1. /2.0/repositories/{workspace}/{repo}/commits/{revision}
   2. /2.0/repositories/{workspace}/{repo}/refs/{branch_name}
2. Branch names with a '/' will not work with any API where the revisions is not the last part of the path. src being probably the most notable
   1. /2.0/repositories/{workspace}/{repo}/src/{revision}/{path}

It's not to say that there isn't any solution, but any solution comes with trade offs and they're not all that great. Here are some solutions that have been brainstormed.

• escape branch names. URL escaping cannot work and the %2F will be re-written before even reaching the app as this is part of the WSGI spec. We'd need to pick a custom character (that is a character that is an illegal branch name character). `\` could work, but I've read that these can be treated as '/' on windows. If we chose to use an escaping solution it will be non-standard and unintuitive and I'm unsure how many people would know about it.
• New APIs. This is the most straight forward fix but also the most change and it could be inconsistent with our other URLs. Revisions can just become query params and the problem is solved.
• Branch lookups - this is possible but could entail a performance hit as we now have to keep track what all the current valid branch names are. Furthermore, this solution is even more difficult with the /src/ API because now we have 2 path arguments that both can contain a slash! We'd have to not only search for possible branch names, we'd have to search within files too. And we still wouldn't be able to eliminate all ambiguity.
• Some sort of a query parameter replacement. Replace the revision segment of the path with '{branch}' and add a query parameter ?branch= and we will substitute that query parameter into the branch name.

I hope you can see that none of the solutions are really that optimal. Please advise on which of these solutions makes sense to you.

As we are currently moving forward to grow our company this disregardful treatment of paying customers (not yet big enough to be heard by Atlassian) is exactly why we now move gradually away from Atlassian and search for more reliable partner which offer their software under a open-source license. Thankfully, I am now in a position to be able to make those decisions.

This bug was opened more than 6 (SIX) years ago and nothing was fixed. This is embarrassing!

2.5 years in and you're "dropping" the priority? How long do minor issues take to fix if higher priorities take this long?

As you can see, I've attempted a fix for this before, however it broke a number of APIs (Everything at https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/commit aside from the basic one) so it had to be reverted.

The way our APIs are structured, it will not be possible to add support to this endpoint for branch names until we release a new major revision because for v2, it will either shadow APIs or some branches won't be accessible.

However, there is a workaround which just involves one additional request to grab the commit hash then using that in any of the endpoints. https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/refs/branches/%7Bname%7D should work with branch names which contain slashes.

I'm leaving this open, but dropping the priority because our hands are tied and there is an existing workaround.

Sorry for the inconvenience.

Happy belated second birthday to this issue...

Hi Zach,

I apologize if my response seemed personally directed at you (it was not) but I hope you will also appreciate my source of frustration here. As you are no doubt well aware, this is one of (too) many Bitbucket issues that have remained in an unresolved state for multiple years now, with no comment or acknowledgment from Atlassian, despite multiple user votes, "+1"'s and requests for status updates. And to me this particular issue is more egregious in that it was (apparently) fixed but then just as quickly reverted with a terse explanation and no follow up despite the comment to the contrary.

So while I am certainly happy to see that some of these issues are getting some long overdue attention and definitely sympathetic to you as the unlucky dude who is tasked with plowing through this mess, I can't help but think that if Atlassian/Bitbucket had not proceeded to ignore them for such a long period of time that they would not be in this position now.

Thank you in advance for all your efforts and I would definitely appreciate it if you could reopen this issue so that hopefully someone can give it another look in the near future.

regards,
-steve