Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Create one pull request across several repositories

We have a Stash Project with ~30 repositories, each containing one submodule. The root-repo (the one holding the git submodule configuration) is also contained in the project. During development we almost always need to change code in more than one module, so we have to create pullrequests in each submodule separately, even if they belong to the same ticket/changerequest/userstory/bugfix.

So, is it possible to create one pull request for changes in multiple repositories?


7 answers

We have a similar situation with pull requests and submodules.  Even without the submodule aspect there may be situations where a global project change may require that the repositories are updated in a specific sequence.  For example for repository B should be merged then repository A should be merged, etc.  Being able to put conditions on a pull request merge might address the OP requirement.  If one could say, pull request A can't be approved and merged until pull B is approved and merged that would at least prevent an out of order issue.  It doesn't address the OP desire to create a single pull request but it means that multiple pull requests are completely independent which might minimize the issue of creating multiple requests.

Yes, some kind of "pull request set/bundle" would be a really nice feature even for a single repository.

i dont think thats possible, because pull-request merges create always a new commit.
And those new commits in the submodules are not the those you have linked in the "parent" pull-request's commit.

In other words: You need to merge the commits in the submodules first before you can even link them in the parent repository.

Nonetheless, it might be beneficial for your scenario if Stash could group several independend pull-requests into one user action.

I think hierarchially linked pull requests are the answer. The pull request is defined based on branches, not commits. Child just needs merged transition to trigger parent Pull Request.


For reviewer it should still be ok, because they are looking at the diff introduced by the software change.

You can create a feature request for this at (check first if one exists already). Please post the link here in a comment if you do.

It could be done with a little bit of code... what links the different changes, do they all have the same branch name for instance?

Sounds great. The branch names are equal, yes (e.g. feature/#123456_foo). Would that require to use ScriptRunner or create a separate addon for Stash?

I would like this feature too. 

I have attached the jira issue that is 99% the answer to this question (as I have interpreted it)

Maybe the people who voted for this answer should vote for the feature request too.

@Craig Hewetson I agree completely! Note, there is also BSERV-9660, created a few years later.

We need to consolidate these efforts to bring Atlassian to more seriously consider providing a solution to gluing together PRs in super-repo and submodules in one atomic action. This is a significant obstacle for anyone using modern software development/CI practices and has a non-trivial project that is forced to use submodules. 

Gitlab 12.2 released this functionality in August 2019, and I endorse their solution, documented here.

I see now that BSERV-9660 is more about collecting superrepo/submodule PRs, whereas BSERV-4577 is more about collecting arbitrary PR dependencies (like what Gitlab Premium now supports).

I am more interested in BSERV-9660, and have reached out to Atlassian support to escalate it, and am taking a dive into the Bitbucket API/SDK to learn about way to implement this myself.

We have faced a similar limitation of the Bitbucket when the project is composed of many repositories that have the same development lifecycle. Thus, to simplify the life of a build-engineer who has to apply mostly the same operations to a bunch of repositories we wrote bash scripts that automate those things with the help of Bitbucket API.

Thanks, @Alex Bondar . I've seen other examples of teams rolling their own "client-based" solutions like this. After my deep dive into server side solutions (using existing plugins and/or rolling our own with the Atlassian SDK), I see the virtues of a client-based solution like yours.

A client-based solution provides simplicity at the expense of elegance

Your users have the extra step (and process to enforce) of running a PR-creation script instead of using the Bitbucket UI for PR creation. This aspect is less elegant than the (hypothetical, non-existent) server-side solution wherein:

The Bitbucket UI for PR creation is modified to automatically observe when (a) the repo contains submodules, and (b) the submodule references have changed in the PR changeset, and then (c) automatically and correspondingly create PRs for the submodule repos.

However, the client-based solution is simpler and certainly more pragmatic since it's easier to attain in short time, and has the added benefit that there is less configuration on the server to maintain. The client-based solution is simply a script that is shared with developers in SCM/git.

Thanks again for sharing your `` solution. :-) I will probably use it as a starting point for our solution. Perhaps I will fork your repo and contribute. We're using Bitbucket Server 6.10, and it will be interesting to see if anything in your scripts is Cloud-centric. EDIT: also I see now that your solution for creating a PR doesn't do anything with submodules, but instead created PRs for all repos in a Bitbucket Project. This is less interesting to me, since we don't have the convenience of all submodule repos being in the same Project, but should still serve as a good starting point. Thanks again. 

Like djilousp likes this

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Bitbucket

Calling any interview participants for Bitbucket Data Center

Hi everyone,  We are looking to learn more about development teams’ workflows and pain points, especially around DevOps, integrations, administration, scale, security, and the related challeng...

504 views 6 4
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you