Degraded performance Customers may experience intermittent errors using Community search. Our platform vendor is investigating.
New pull requests provide the option to choose a destination repository and branch. I can set the default branch in Settings>Branching model but I need to be able to set the default repository too. Is this a known/missing feature?
Our feature branches are made in a public fork, we'd like them to default to their upstream/parent repository when pull requested. Private forks seem to behave this way already. It is too easy to send the pull request to the fork's own master by mistake. While users can edit the details an existing pull request, the destination repository is not one of the details that can be changed. Is this also a known/missing feature?
To close the issue for now (pending any resolution to STASH-5201)
If a pull request destination is accidentally left at the default "master within the fork" it is impossible to change it when editing the existing pull request details later. The only corrective action involves declining the existing pull request and creating a new one taking care to pick the upstream project.
I was a bit confused with your description. Could you please outline the detailed steps of how you are reproducing the issue and what the issue is?
I found STASH-5055 could be what you are hitting. Please let me know if that's the case.
Sure, here's a detailed outline
Note that the resulting "Create pull request" Stash page has defaulted the destination project and repository to development:myRepo instead of upstream:myRepo. Since development:myRepo is a fork of upstream:myRepo it would seem logical that the default pull request destination be upstream:myRepo. If not the default then it should at least be configurable along with the default destination branch which *is* configurable in Repo>Settings>Branching model. I think the additional layer here is that fork is in a separate project.
Does that help?
Thanks for detailing more your question.
The behaviour you described is correct and it is following the Forking Workflow:
How It Works
As in the other Git workflows, the Forking Workflow begins with an official public repository stored on a server. But when a new developer wants to start working on the project, they do not directly clone the official repository.
Instead, they fork the official repository to create copy of it on the server. This new copy serves as their personal public repository—no other developers are allowed to push to it, but they can pull changes from it (we’ll see why this is important in a moment). After they have created their server-side copy, the developer performs agit cloneto get a copy of it onto their local machine. This serves as their private development environment, just like in the other workflows.
When they're ready to publish a local commit, they push the commit to their own public repository—not the official one. Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated. The pull request also serves as a convenient discussion thread if there are issues with the contributed code.
In regards to your feature branch question, is described further down on the same page:
Branching in the Forking Workflow
All of these personal public repositories are really just a convenient way to share branches with other developers. Everybody should still be using branches to isolate individual features, just like in the Feature Branch Workflow and the Gitflow Workflow. The only difference is how those branches get shared. In the Forking Workflow, they are pulled into another developer’s local repository, while in the Feature Branch and Gitflow Workflows they are pushed to the official repository.
Let me know if this explanation makes it clearer for you.
Thank you for the documentation, it is very helpful. After reading it I see that our flow differs in that our team of 150 developers clone from the same fork in a Stash project called "Development". It is a fork of a repository in another Stash project called "Upstream".
When a pull request for a feature branch is created in the Development project Stash defaults the destination to the Development project.
We'd like it if Stash had the ability to recognize that the Development project is a fork of Upstream and default the destination to the Upstream project instead.
So while we are using the forking workflow, we do not use personal projects to store the fork because of the amount of plugin configuration required for each fork.
Does that help explain what we're doing? Perhaps this is an enhancement request?
I see your point now. Thanks for detailing all your answers! I tested on one of our recent releases and I also believe that Pull Requests created off forks within your profile should behave the same way as when you are performing the same actions for a fork residing on a project.
Based on that, I raised the following suggestion:
I would strongly suggest that you vote on this issue to increase its popularity and add it to your watchlist for future updates.
Please check how Atlassian implements New features and Improvement Requests for more information.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs