+1

+1

+1

+1

+1

+1 This would be a great feature!

+1 on this and that one: BCLOUD-13645

+1

+1. We'd definitely love to see a resolution for this feature.

Attachment 1198483264-Screen%20Shot%202019-04-30%20at%2010.32.28%20AM.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

Attachment 562409127-branch-view.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

Attachment 1289014065-pull%20destination.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

Attachment 918744398-branch%20base.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

Attachment 2149422320-20180328-TortoiseHg-1-.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

Attachment 1891202837-20180328-mercurial-1-.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master

I came here to support @mattmccutchen with exact same issue. This made me waste time looking for the PR, because depending on source destination the associated PR will show.

I filed a support request that the "change destination" link on the branch page is misleading (it looks persistent but actually only affects the current page) and was told that the misleadingness would not be addressed separately from the actual persistence requested by this issue report. Adding a comment to help the next person find this issue report.

If you email Bitbucket support they will happily change the base repo for you. They usually have done it for me in a few hours.

Dave

Right, that works if you come from the Feature Branch page, but I’m talking about the Pull Request page

Hi @dandelaney8,

In the same page, Branching model, in the top of the page, you can select the Development branch and Production branch.

I set up Developement brach as Develop and Production branch as Master an it works for me.

After creating PR from a feature branch, it’s selecting auto the Dev branch.

It’s not enough to set one default branch. I want the target branch to be, by default, the one from which the source branch was branched. The use case is that we have release branches (v1.1, v1.2, etc.) and to make a hotfix we create feature branches off those. We then want those to be merged back into the release branch from which they were created.

At least for cloud, you can put in a support request and they can re-point the default PR target. We eventually had to do that for our app as the same thing was happening, the giant unneeded diff was crashing the page.

‌

This could and should still be changed to be user configurable, at the very least retaining the last-selected target in the UI.

The branching model stuff is great, and that helps when creating a pull request directly from a branch, but there’s still the issue of the underlying main branch & repository.

When I go to the Pull Requests page and click the “Create pull request” button on the top right corner, it defaults to the master branch of the repository I originally forked. I forked a base template of my framework setup and have no intention of ever merging these new changes back into it, because this is a completely separate project. Image attached for reference. When this starts loading the diff/commits for the PR by default, it ends up breaking/crashing the page because it’s trying to compare way too many changes. Any fixes coming for this ever?

Hey guys,

It was already implemented.

You can see here
https://bitbucket.org/blog/introducing-bitbucket-branching-model-support

Here it’s possible to configure it. We’re using right now in the company.

I would like to see this change implemented as well.

I need this for reasons

HEY YES PLEASE SUPPORT THIS

+1. When creating Pull Request, default target branch should be the one the new branch was branched off.

Can we just get access to the post-receive hook to generate the url ourselves? When you 'push' you get back a URL to create the PR. In the URL if you set the GET parameter 'dest' with your desired destination branch it already works. We just need to be able to modify how that url is generated. I can't find a way to do that anywhere.

I support this change.

Or save the "branch from" option in each branch. Don't let this request slide, it'll saves so many users so much time & frustration.

+1!

I'd like to echo my support for the ability to set a default branch for pull requests separate than the default branch of the Git repo too.

+1

Our repository started as a fork of a repo, but has never needed to merge anything back into the original repo, as it was just a template. Now every time I go to create a new pull request, it defaults to updating the original repo, and practically breaks the page every time because there are too many changes for it to compute.

Please fix this!

+1, this would be so useful!

Issue BCLOUD-17019 was marked as a duplicate of this issue.

Yes! This would be great to have.

This issue predates me becoming a full-time developer. It will be a strange day when it's finally resolved, it feels like a child to me at this point.

@datamafia I'd give you an upvote if I could.

For 4 year old issue of required parity with a leading competitor where the lack of feature is causing time and money to be lost for dev teams shows a tone deafness underscoring why my only use of Atlassian products because of existing client dependencies. My experience in the Atlassian suite for over a decade is exemplified by threads such as this one. I am in a bind currently where this EXACT setting just cost hundreds of dollars for a team who is accustomed to GitHub's "pro-developer" operation. Considering recent ownership changes at GitHub it would only make sense to be sensitive to issues of this nature to onboard people departing because of Microsoft ownership. But alas, Atlassian again shows a commitment to the ecosystem best described as ignorant and offensive. I am closing in on 20 years in development personally and I am repeatedly shocked at the poor quality put forward. As a successful business man once said to me "the people who walk away quietly do the most damage to your business".

Issue BCLOUD-16171 was marked as a duplicate of this issue.

+1, would be handy to have default branch for PR configurable and being not the same as repo's def branch.

Issue BCLOUD-16945 was marked as a duplicate of this issue.

@aneita and @Alistar, I don't believe I understand. when you say
" [...] The team is working on higher priority projects including:

• improving the pull requests experience
• improving design and user experience.

How is it that this topic can be omitted from one or both of these 'high priority' topics?

Also we forgot this issues fourth birthday. We're all bad parents.

Why would the "main" branch be called "develop"? We follow Driessen's "A Successful Git Branching Model" and calling it develop would be extremely confusing. We've put legacy apps in a different repo, but could and would probably like to have a "Legacy" branch, with a master for the newer branch, and dev, stage, prod branches to match up with our dev, stage, and prod servers.

Hi y'all,

Time for another update - we are still working on improving the pull request UI (which you can test out soon!). As Aneita said, this feature is not at the top of the list right now, but it may be in the future.

There have been a few questions about this in recent comments, so I do want to restate one thing: there is already a repo setting for the default target branch ("Main branch"). So for example, most of your PRs are going to be merging into develop, we recommend changing the "Main branch" of your repo to develop.

This issue is about letting that be overridden (or auto-detected) on a per branch basis, to enable more flexible workflows.

Thanks,
Alastair

+1 please, GitHub can do it, why not you

+1 please

+1 please

+1, please.

This has our vote! +1

While I appreciate the work that has gone into the Pull Request experience...This feature is long overdue. This would go a LONG way to reducing development friction (including accidental targets to the wrong repository since you do not support detaching forks and cannot re-target the repository).

++1