Mark pull request as depending on another

[OliverJAsh]

Quite often I find myself raising a pull request that contains another within it as a dependency. I want the diff to be exclusive of the dependency pull request’s changes, otherwise my colleagues end up reviewing more than they need to, or worse, the same changes twice (in both pull requests).

To workaround this, I usually set the base of my pull request to the dependency pull request, however this has caveats:

• When the dependency pull request is merged and the branch is deleted, the dependent pull request will be automatically closed.
• When the dependent pull request is merged, it is silently merged into the dependency pull request. This is usually not intentional.

I would like to see some UI in GitHub to make this workflow first class:

• Dependent pull requests should not be mergeable until all dependency pull requests have been merged

[cirosantilli]

related #210

[phil-davis]

It would be nice if the branch to which the PR is targeted even automagically updated:

1. PR branch my-new-infrastructure-thing is awaiting review and merging to master.
2. PR branch my-new-ui-thing is made against my-new-infrastructure-thing (because it makes use of some new infrastructure in my-new-infrastructure-thing)
3. Diff of PR my-new-ui-thing just shows the diffs to my-new-infrastructure-thing
4. When my-new-infrastructure-thing is merged to master, PR for my-new-ui-thing automagically switches to being a PR against master.
   (and mostly there will be no conflicts to resolve, but there could be because other stuff might have happened in master also that causes conflicts - those would be resolved by the person who "owns" my-new-ui-thing, like they would for any conflict situation)

[aspiers]

See also #805 (can't move base branch of PR to a different fork).

[gelldur]

Also after merging branch cache still shows changes from dependent branch

[dstanek]

This is a feature that I really miss from Gerrit. It's more common for me to have pull requests that depend on other pull requests than to have isolated pull requests.

[courtney-miles]

When my-new-infrastructure-thing is merged to master, PR for my-new-ui-thing automagically switches to being a PR against master.

This is the workflow I imagined also. The dependant PR should follow the merge of its dependency.

[brauner]

Fwiw, I had requested something similar directly from Github in 2016:

From [email protected] Wed Feb  3 14:02:38 2016
Date: Wed, 3 Feb 2016 14:02:38 +0100
From: Christian Brauner <[email protected]>
To: [email protected]
Subject: Incremental pull requests
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)

Hello,

I have a feature request/suggestion/question. A workflow that happens rather
often is to have multiple but not-thematically connected commits but which
nonetheless are incremental, i.e.

        Commit 1:
                - Implement **A** by making changes to file **F**
        Commit 2:
                - Implement **B** by making changes to file **F**

Where the features **A** and **B** are not thematically connected but make
changes to the same file and functions therin and are thus incremental (i.e.
build upon each other).

Let's assume I implement feature **A** first. Then I create a new branch

        git branch implement_feature_**A** origin/master

based on the current master. But for the implementation of feature **B** I would
logically use origin/implement_feature_**A** as base

        git branch implement_feature_**B** origin/implement_feature_**A**

Is there a way to group these PRs together such that it is obvious for other
collaborators that they should be merged incrementally, i.e. first merge

        implement_feature_**A**

and only then merge

        implement_feature_**B**

?

Otherwise they could always just merge

        implement_feature_**B**

and the PR for

        implement_feature_**A**

becomes rather pointless + this way neglects the fact feature **A** and **B**
are just incremental but thematically unrelated.

Best,
Christian

They told me that they'd consider it:

Date: Tue, 09 Feb 2016 04:52:55 -0800
From: "Petros (GitHub Staff)" <[email protected]>
To: Christian Brauner <[email protected]>
Message-ID: <discussions/73b2738eca7611e58e1586af4be1788f/comments/[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Subject: Re: Incremental pull requests
Mime-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-SG-EID: /isQyw1HWYOYdYDPy2G3B3zgegQeGDLWVRLJ7aoZ5uDHe0Js9MIhxWsZqnOheP5i+al8M60D37ZiLY
 5SddaxWW+FNYaG5PkvackH0fkAZe5afVFP4jCsqJB8ea/RmszlNd0mJq4qFA8yV4FKAX0jbkzV8vom
 3Dfb1nCfmOCEdYRQtnT6DdFtY0jlys6BwwBO6u12YIzcENYjHB0KbK9BK6Qi3IHc2j9UPJ18IoEzuq
 p8tsl0ud7oezPxxmCSdYg+

Hi Christian!

Thanks for writing in!

> Is there a way to group these PRs together such that it is obvious for other
> collaborators that they should be merged incrementally, i.e. first merge

Not currently. You could use labels, group them together by using a prefix in the title, and as always, communicate your intentions in the pull request body by mentioning your team(s) or other collaborators.

Your feedback is interesting, so I have shared it with our team to consider.

Cheers,
Petros

[aspiers]

Duplicate of #950 and #867, although this one has more interesting comments than those.

[MV10]

This is especially annoying when the repo you're contributing to can take weeks to review / merge, and devs are left having to somehow manually keep track of the follow-up changes instead of getting completed work into the pipeline and move on with their life.

[wxianxin]

Is it normal that an issue has been open for over a year?

[dgw]

This is just an unofficial "ideas" repo. GitHub doesn't officially follow these issues.

[amcsi]

GitHub should make it so that if a dependency PR was merged, all dependent PRs that had that merged PR's branch as a base should automatically have their base branches changed to that of the merged PR.

This way it would become really straight-forward to merge PRs in a bottom to top approach (merging PRs closer to develop first).

[aspiers]

@amcsi commented on November 29, 2018 11:07 AM:

GitHub should make it so that if a dependency PR was merged, all dependent PRs that had that merged PR's branch as a base should automatically have their base branches changed to that of the merged PR.

This way it would become really straight-forward to merge PRs in a bottom to top approach (merging PRs closer to develop first).

Agreed. The need for this auto-rebase (or at least auto-change-base) feature was also noted in #950.

[OliverJAsh]

These might help:

• https:/ryanhiebert/probot-chain
• https:/z0al/dep

[pmalekn]

So is there any chance that we're getting this
What's the status of this? I assume that if the issue is still "Open" it might get implemented.

[karlhorky]

Wonder if this "early next year for stacked diffs" tweet by Nat has anything to do with this discussion: https://twitter.com/natfriedman/status/1170804894241972224

[gregsdennis]

Here's a GitHub action that does this: https:/marketplace/actions/pr-dependency-check

[z0al]

FYI, I just released Dependent Issues 🎉 . The successor of the 3 years old DEP bot.

It's a GitHub action that lets you mark a PR or an issue as dependent on another. It works with cross-repository dependencies as well.

Check the repo for more info: https:/z0al/dependent-issues

[jd]

For what it's worth, it's now also a feature in Mergify. When using the merge action, which enables automatic merge, it'll respect Depends-On headers.

[ejoffe]

Also suffering from these same stacked pull request headaches, I wrote a client side tool that manages pull request stacks for you automagically.
If you like the gerrit style workflow, checkout git spr https:/ejoffe/spr.
For me it has brought back sanity to managing pull requests on github.
I'd love to get your feedback.

[oprogramador]

@OliverJAsh

Are you going to clone this proposal to https:/github/feedback/discussions ?

[aspiers]

@oprogramador commented on July 6, 2021 3:52 AM:

@OliverJAsh

Are you going to clone this proposal to https:/github/feedback/discussions ?

This was already done, so please don't submit a duplicate - thanks ;-)

[oprogramador]

@oprogramador commented on July 6, 2021 3:52 AM:

@OliverJAsh
Are you going to clone this proposal to https:/github/feedback/discussions ?

This was already done, so please don't submit a duplicate - thanks ;-)

Thanks.
Sorry, I submitted this as I was able to find neither Mark pull request as depending on another nor Mark pull request as depending nor depending on another as the new title is Make Child Pull Requests Dependent on Parent Pull Requests. I wasn't able to find feedback/ in this issue discussion either.

[aspiers]

@oprogramador commented on July 8, 2021 7:51 PM:

Sorry, I submitted this as I was able to find neither Mark pull request as depending on another nor Mark pull request as depending nor depending on another as the new title is Make Child Pull Requests Dependent on Parent Pull Requests. I wasn't able to find feedback/ in this issue discussion either.

No worries. But that exactly proves the importance of GitHub doing this migration properly, and quickly. Please can you link to the discussion you filed, and also close it with an explanation which links to community/community#4477 and to here?

[oprogramador]

I haven't opened any discussion related to this issue.

[aspiers]

Ah I see, by "I submitted this" I guess you meant "I wrote the above comment" rather than "I submitted a new discussion topic". I misunderstood it as meaning the latter.

[oprogramador]

Ah I see, by "I submitted this" I guess you meant "I wrote the above comment" rather than "I submitted a new discussion topic". I misunderstood it as meaning the latter.

Yes, I meant posting a comment.

[webzorg]

It would be stupidly easy to implement this feature but yet this issue is open for a decade. 2021!

[Levi-Lesches]

@webzorg There are a few custom solutions:

• dpulls, from @Fakerr (Mark pull request as depending on another #959 (comment))
• Dependent Issues, from @z0al (Mark pull request as depending on another #959 (comment))
• PR Dependency Check, from @gregsdennis (Mark pull request as depending on another #959 (comment))
• Blocking Issues, from me!

The GitHub team can't possibly be expected to implement every possible feature that everyone wants. That's why they gave the open source community access to GitHub APIs, GitHub Actions, and GitHub Apps. If there are community-run solutions out there, I encourage you to use them. And if they don't exist, make them!

[gregsdennis]

... Dependency-check from me

[Levi-Lesches]

Thanks, added to the list. I'll use that list if similar discussions arise.

EDIT: Here's the discussion on the official GitHub feedback repo: community/community#4477 (comment)