Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Bitbucket Workspaces FAQ


What if we have multiple repositories that we want to include into an application, but they are in different private workspaces?


For example:


For example, I have my auth.json file, with the following structure:


"bitbucket-oauth": {
"": { 
"consumer-key": "",                
"consumer-secret": "",                
"access-token": "",
"access-token-expiration": 99999           

With workspaces, consumers are defined for each workspace.

So if there are multiple consumers/tokens to be added, how can this be done?
Or maybe there is a different approach?


While I've been using Jira for nearly five years, I've had to back away from BitBucket several times.

First because the Documentation was simply unusable - contradictions and misleading statements everywhere!

But the stinking pit of the problem was the insane structural hierarchy of 'Projects', Users, Teams, Repositories, and the immensely ambiguous 'your work'!

I have repeatedly complained bitterly about this ridiculous 'convoluted upside-down and backwards' approach that made all the elements in the organization of the user interface and all attempts at reasoning and rationale simply impossible to anticipate and properly organize any significant pattern of repository grouping and statusing.

And most infuriating was the fact that the structural gastrointestinal shape of the verbal but non-logical relationships among the elements could never be reconciled with any repetitive workflow organization conceptualizations.... BECAUSE.... BECAUSE!!! the structure was not a representation of real-life relationships among the Source Management Components we are all familiar with!!! 

They were simply a TAXONOMY: a series of words that did not possess any functional infrastructure to actually connect the 'meaning' of projects, or repositories, or teams, or any real-life operational results.

And all the changes that have been introduced in the past 5 or 6 years, each of which was touted as a 'revolutionary alteration' of the guts of Bitbucket, were simply changes in the naming of the TAXONOMIC elements with no functional changes to the way the wacky, weird, and perplexing puzzle of how to organizing our repos and their real-life relationships using this TAXONOMY represented as operational logic.

And the introduction of a NEW TAXONOMIC Element: 'WORKSPACE', still, once again, a non-functional, totally abstract Nomenclatural nothingness... demonstrates that the design team for this flimsy Interface that has yet-again decided it was too difficult to rebuild the system from the bottom up, is just selling another candy-wrapper to developers  for whom they clearly have no respect.

In this subsequent re-attempt to 'bait and switch' they have stolen the NAME of an already existing element in the actual, real, substantial, and meaningful TAXONOMY of Git in all its ingenious precision and smoothly operating integrations.  We already know what a WORKSPACE is, and forever OUGHT to be!

Its an artifact of a FILE SYSTEM that becomes the overall boundary of a body of code that is enabled to manage all the complex operations of the current version of GIT because of the existence of a hidden NUCLEUS containing the core operations that makes the vast numbers of Commits to a GIT Repository throughout the lifetime of a development team's determined effort to assure that GIT properly manages all the variations of ingenuity of a team's effort.

It simply is not proper for a commercial entity to misappropriate this fundamental term of our work product and the necessarily precise activities and disciplines we utilize to succeed from a design and business sense, just because they have locked themselves into a strange, totally conflicted, primitive, and inappropriate taxonomy that they continuously shuffle and surreptitiously put on and remove from the board they have been using to hide from their management their mistaken plan of renaming the clearly disorganized and unusable infrastructure of their source control application.

They need to take a year or two to really redesign this product and stop trying to camouflage their inept attempt at fooling all of us with their terminology trick.

Take a serious look at their newly revised diagrams of teams, users, repos, and their ownership/responsibility chains. It's the new version of their hoax!

I'm just going to ignore their crude attempts to emulate GitHub and just use it as a big repo. Until they get honest about this situation, I recommend everyone else do the same.


Log in or Sign up to comment

Atlassian Community Events