Repo>Settings>Branching model assumes current repo

Stash v2.12.4

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?


3 answers

1 accepted

0 votes
Accepted answer

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.

0 votes

Hi Seth,

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.

Best regards,

Thiago Bomfim

Atlassian Support

PS: the issue I linked you to only happens to non-personal forks.

Hi Thiago,

Sure, here's a detailed outline

  1. create a project called upstream
  2. create a repository in upstream called myRepo
  3. create a branch in upstream:myRepo called master
  4. create a project called development
  5. fork upstream:myRepo:master to project development
  6. create a feature branch from development:myRepo:master called feature/one
  7. make an edit to feature/one and commit/push
  8. begin a pull request for feature/one

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?



Hi Seth,

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.

Best regards,

Thiago Bomfim

Atlassian Support

Hi Thiago,

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?



Hi Seth,

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.

Best regards,
Thiago Bomfim
Atlassian Support

Thanks Thiago, I voted, commented, and am watching the STASH-5201 now. I appreciate your effort to understand my sometimes cryptic means of explaination.

0 votes

PS: the problem I linked you to only happens to non-personal forks.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 06, 2018 in Bitbucket

Upgrade Best Practices

Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...

1,961 views 7 10
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you