I'm always shocked to see such simple tickets unsolved for almost a decade.

The raw endpoint does work with %2F.

Me too on this one.

I've been affected when writing release notes. We keep those in Bitbucket too, and so I'd like to be able to put a link to the Readme for an item in another repo, on a release/ branch  in the description. The link is commit-scoped, so I have to update the release note by hand all the time.

I don't quite get why the url-encoded approach wouldn't work - it should be extremely easy to implement since existing routing behaviour will not be affected - all you need is to urldecode() the same path segment currently in use.

We've been waiting 7 years (and counting) for a 5-minute change.

is there an update / workaround for this issue? as mentioned here in the thread - it's a big issue with using the API..

This is a CRITICAL bug affecting usability of the tool. Linking to the latest version of the source (or most commonly some .md file) is a key for easily maintaining documentation references.  It is also related to the inexplicable lack of native linking from Confluence to Bitbucket. On top of it, this bug make a 3rd party solution from mibex effectively useless.  Atlassian - please get it together...

For some reason, the urlencode trick works when viewing raw files. For example:

https://bitbucket.org/guyzmo/git-repo/raw/bugfix%2Fconftest_fix/tests/conftest.py

So, Atlassian guys could check out that code and integrate the URL decoding solution (one line or function, i suppose) to src view, too. Although, there must have been a reason to use a more complicated way (?at=<branch/name>) instead.

This bug prevents linking content from Bitbucket to Confluence using branch name.

I'm using Confluence cloud Asciidoc macro to load an Asciidoc file from Bitbucket to Confluence. On branches without slash on their name I can link a file in a branch, so the latest commit is always loaded regardless of how many commits are pushed, but when there is slash on the name, I have to update all pages using Asciidoc with Bitbucket and slash as source branch, meaning when updating the repository I have to also manually update the source url in the Confluence macros, meaning it is so impractical that I would consider it impossible for humans without external scripts.

I respectfully disagree. People reasonably tend to get quite upset when they are unreasonably losing their money. 

We have paid good money for a broad set of Atlassian services for nearly a decade. I have opened and contributed to issues that go ignored for years.  That's an absurd amount of time in any industry, let alone software. I'm tired of being treated this way when my company has invested so heavily in Atlassian's platform.

We have built many automated workflows that rely on these naming conventions that seem to be quite common. This bug (and many others like it) are killing my team's productivity and costing us real cash. I'm livid.

Hey @Sam, I'm as critical as the next guy, but I'm not sure getting petty, snippy and just plain rude is the best way to go. Ever head the phrase "you catch more flies with honey than vinegar?"

All in all, I am in awe of everything their suite of tools is capable of. Does it have some warts, for sure, but most things work as advertised.

Hey you slackers at Atneverian! Isn't it strange that this bug exists when:

• the gitflow dialog in SourceTree suggests branch names with slashes
• The SourceTree branch view is aware of slashes since it provides a tree view where slashes delineate levels in the hierarchy
• The "Branching model' page under project settings on the website is also is aware of slashes

It seems kind of stupid to have built all that functionality, but somehow simple URLs to these resources are broken. 

Perhaps an employ could at least comment on this thread? Are your offices empty? There are a lot of users here that ARE TIRED OF THIS ECHO CHAMBER!!!! There so many issues for major bugs that have been open for YEARS! How about you earn your keep and support the garbage you sold us? 

Sincerely,

A very disgruntled PAYING customer