I think you have landed on the very motivation behind, and the very benefit that pull requests offer over patches. The submitter(s) is/are the one(s) who know how the pieces fit together. It is they that are responsible for creating something that's mergeabel. A set or PRs with a "No conflicts" status.
Just imagine the streams of patches that come in chunks as individual PR. If after 1 PR comes in it causes a second PR of the groups to become conflicted. The onus is on the submitter to rebase and resolve the issues. On past projects that I have worked on the process was to carry patches and apply them in the build. This gave me a sense of security in that I could see all of the deltas from upstream in the patch set. Then other members of the team suggested that we carry these changes as commits on top of (re based on) upstream. This left me totally uncomfortable because it completely changed the why I was working. But what I learned was the key benefit of this methodology is that: it is far better to find the conflicts during a rebase in a git re base session then it is to try to decipher failed patch applications in a build. After doing it with this re based workflow I realized the benefits. It was super uncomfortable at 1st but now it's 2nd nature and much, much more efficient not to mention foolproof. This is essentially what happens when A PR Has conflicts and the submitter is asked to resolve them. They re base on the current master and they are very quickly able to ensure their changes are now proper in the new context. David On Tue, Dec 24, 2019, 2:52 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > If they are related / dependent on each other, then I think those > > kinds of patchsets should be encapsulated in one branch. > > The need to be applied and committed in sequence. Sometimes the final > patch is the one that fixes the coding style. This is inherently very > manual. > > >
