GitHub Community
Make Child Pull Requests Dependent on Parent Pull Requests #4477
Replies: 7 comments 11 replies
-
|
See isaacs/github#959 which is the main issue in that repo covering this topic; isaacs/github#867 is a kind of early duplicate. At the time of writing it has 580 👍, 91 ❤️, 34 🚀, and a lot of valuable discussion which I worry will be forgotten about by simply copying issue descriptions here. I suggest leaving GitHub staff to take care of migrating issues from https://github.com/isaacs/github/issues to here, since they are already working on that and (hopefully) listening to various suggestions on how to perform the migration in the most effective manner. |
Beta Was this translation helpful? Give feedback.
-
|
They’re welcome to do a migration and preserve more than the initial description, and I’ll close this when they do. Thanks for linking the main issue that has more discussion. I don’t think we lose anything by creating discussions here opportunistically in the meantime. From your “already working on that” link it doesn’t seem they’ve actually committed to migrating anything at all, much less that they’re already working on it. All I see there are requests to migrate. |
Beta Was this translation helpful? Give feedback.
-
|
@sbrocket commented on July 2, 2021 10:39 PM:
I think the downside is that it further fragments discussions on the same topic. I admit it's not a massive problem since a fair amount of fragmentation exists naturally anyway (and probably always will with anything which has such a huge user base). Nevertheless, where possible it's nice to try to reduce an existing problem, or at least avoid compounding it further.
It's probably correct that there has been no clear commitment to any specific action yet, but I am (currently) quite a bit more optimistic than you, for reasons explained below:
No, there is more than that for sure. @michellemerrill has very clearly asked for feedback on how a migration should best be handled. I haven't yet seen responses to the resulting feedback, but it seems unlikely anyone would ask for feedback on a migration unless they were actually seriously considering going ahead with one. Hopefully we'll get more updates soon. Also see isaacs/github#1967 for the context behind how this initiative came into existence. |
Beta Was this translation helpful? Give feedback.
-
|
I open sourced a tool that integrates into git and manages the stack of pull requests for you. This both reduced the load of having lots of branches and managing their base refs, as well as the issue you are bringing up of not merging child pull requests before their parents. |
Beta Was this translation helpful? Give feedback.
-
|
I used to work using Gerrit in my previous company, and I completely agree with you that it's a superior approach. |
Beta Was this translation helpful? Give feedback.
-
|
@ejoffe thanks for linking to We just moved to use GerritHub for the CUE project: as you say, the integration is not perfect, but the GerritForge team have been very responsive to requests/issues. |
Beta Was this translation helpful? Give feedback.
-
I use Gerrit and GitHub review daily. Being able to stack reviews like this is the biggest reason I strongly prefer Gerrit for code review. |
Beta Was this translation helpful? Give feedback.
-
|
@ejoffe I've been using https://github.com/ezyang/ghstack, which seems to do something very similar to your tool. Have you seen that? |
Beta Was this translation helpful? Give feedback.
-
|
@amartani - Yes, I have tried out ghstack, and I think it's a great tool. It's achieving the same goal, but a little differently. From what I remember ghstack creates 3 remote branched for each commit, spr tracks commits a little differently by adding a generated commit-id to the commit message (just like gerrit does it) and only creates a single branch. Feel free to try it out, would be interesting to have feedback from someone that used both tools. |
Beta Was this translation helpful? Give feedback.
-
|
This feature is basic common sense, it has to be the top prio! |
Beta Was this translation helpful? Give feedback.
-
|
There are already sevaral solutions in place for this, written and maintained by the open-source community:
And probably more. 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! That being said, this discussion should probably remain open until GitHub staff gives their official verdict. |
Beta Was this translation helpful? Give feedback.
-
|
I believe there are two related but distinct value-add features being discussed here around forming relationships between PRs. I'll try to write up a summary. To illustrate, lets use an example. Lets say I'm making two dependent PRs to the repo
Feature 1: Render PR2 as a diff from PR1Case A: Author of both PRs has push access to
Case B: Author is external to
@ejoffe's https://github.com/ejoffe/spr attempts to streamline this process clientside for Case A. AFAICT it is not possible to build such a tool for Case B as I don't think customizing the diff renderer is possible in this way. There's some further discussion of this in an issue on the github cli cli/cli#2693 (comment) Feature 2: Block PR2 from landing until PR1 lands.@Levi-Lesches's comment #4477 (comment) has a great writeup on various external tools which do this. This is possible to achieve via github API, even w/o a blessed way to encode the dependency. Encoding the relationship between PRsGithub doesn't have a blessed way to encode relationship between PRs. Several tools exist which try to cover feature 1A and feature 2, which leverage different encoding schemes. I've found popular ones to be
|
Beta Was this translation helpful? Give feedback.
-
|
This is an excellent summary of the problem - there are in fact two separate challenges here. In my opinion, the community solutions for "Feature 2: Block PR2 from landing until PR1 lands" are pretty good and sufficient. However, the solutions to "Feature 1: Render PR2 as a diff from PR1" are far more limited (with apologies to the I feel it is in the area of Feature 1 that GitHub itself could really make a difference. |
Beta Was this translation helpful? Give feedback.
-
|
Seriously? After all these years it's still not possible. "Use the API or use community actions." Not possible if the respoitory you are opening such pull requests for on which you do not have write access on and so must be forked. The inability to be able to mark child pull requests ticks me off considerably. Because this does not exist, it makes it insanely easy to get your default branch into an unbuildable state if you accidentally merge the child before the parent. Likewise I feel like merging the parent PR should automatically merge the child pull requests at the same time for us. For this reason I feel like the only way to be able to get such done would be to make my own git website to host projects on in order to use such a feature. However currently I do not know how to use .NET to make an git server side similar to github yet 😄. |
Beta Was this translation helpful? Give feedback.
-
Alternatively, petition the maintainers of that repository to add a workflow that solves your problem instead of expecting the GitHub team to offer every possible feature all at once (and ask them to prioritize one over the other). If your use case is convincing, you can make a strong case. Again, I'm really not saying that using community actions is a permanent fix -- I'd love to see this supported natively, like closing keywords. But you have to understand that GitHub is still working on adding many new features (they just revamped projects!) and until the one you want is addressed, you have to make a solution or use one provided by the community. That's why this discussion is still open, to provide GitHub a chance to address this need. Also, by making our own solutions, we get to set the status quo for what the "ideal" implementation should look like, which GitHub would then follow, instead of the usual "GitHub made this a built-in feature, but we need X, so we're going to use Y instead". |
Beta Was this translation helpful? Give feedback.
-
|
I’ve been using graphite.dev which has been great for the you-have-write-access use case (1A). Still looking for a good solution for the fork/PR workflow (1B above). This one is difficult to solve without help from github. You can submit the PR within your fork as a workaround, but the maintainer wouldn’t be looking at PRs in your fork. |
Beta Was this translation helpful? Give feedback.
-
|
Until now, seems like github does not want to implement it. For those who are looking at a step-by-step guide you can check This blog |
Beta Was this translation helpful? Give feedback.
-
Moved over from isaacs/github#867, which currently has 100 👍
Description copied from there:
GitHub currently allows you to change the base branch of a pull request, which would allow you chain pull requests together so that the unique diff can be seen. The issue with this is that it only works with upstream branches.
I would like to have the ability to mark a Pull Request as a Child of another pull request. In this case the child PR would not be able to be merged until the parent is merged or the marking is changed. Also, the diff would only show the differences in regards to the parent PR.
These features are not possible when continuously working on a feature or set of features that depend on each other and require review merging one piece at a time a branch or number of branches ON A FORKED BRANCH. This often leaves me having to manually manage a chain of branches on a local repo, getting feedback on one piece at a time without a reviewer being able to see the upcoming changes as well.
Beta Was this translation helpful? Give feedback.
All reactions