nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Repo>Settings>Branching model assumes current repo

Seth Carter_v7wimc

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?

Thanks,
Seth

Accepted answers

Seth Carter_v7wimc

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.

All comments

ThiagoBomfim

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

ThiagoBomfim

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

ThiagoBomfim

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

Seth Carter_v7wimc

Hi Thiago,

Sure, here's a detailed outline

create a project called upstream
create a repository in upstream called myRepo
create a branch in upstream:myRepo called master
create a project called development
fork upstream:myRepo:master to project development
create a feature branch from development:myRepo:master called feature/one
make an edit to feature/one and commit/push
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?

Thanks,

Seth

ThiagoBomfim

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

Seth Carter_v7wimc

To close the issue for now (pending any resolution to STASH-5201)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

bitbucket-administration