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 christian.brauner@mailbox.org Wed Feb  3 14:02:38 2016
Date: Wed, 3 Feb 2016 14:02:38 +0100
From: Christian Brauner <christian.brauner@mailbox.org>
To: support@github.com
Subject: Incremental pull requests
Message-ID: <20160203130238.GA27328@mailbox.org>
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)" <support@github.com>
To: Christian Brauner <christian.brauner@mailbox.org>
Message-ID: <discussions/73b2738eca7611e58e1586af4be1788f/comments/2614357@github.com>
In-Reply-To: <20160203130238.GA27328@mailbox.org>
References: <20160203130238.GA27328@mailbox.org>
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.