0

I'm likely to start working on a pull request for an open source project. Most of the code that is being added will be independent of the rest of the project, essentially CMake files to aid with building a variant of the main project. In my initial plan of work, I've identified that some changes will be needed in the main sources, mostly regards removing legacy code that isn't needed and will obstruct the rest of my work. As those changes are of general use in tidying the project, I'd like to be able to submit them independently of the overall pull request.

I'm going to be forking the main repo as I'm not a maintainer, and creating a cross-repo pull request. I anticipate creating a draft PR for the main changes, with ready to merge PRs for those tidying commits.

There is no guarentee that the maintainers will merge the sub-pull requests until they see the outcome of the rest of the work, but I don't want them to get lost amongst all of the other commits for the long running branch.

I'm presuming that I can add commits to my monolithic branch, and when I spot a change that is useful aside from everything else, I can create a new branch from master, cherry pick the necessary commits, and then create a pull request for that sub branch.

What will happen when the maintainers merge any of the sub-PRs and/or the monolithic PR, and what will happen to my local if I rebase from master when some/all of the sub-PRs have been merged, prior to my mono-PR being submitted as final?

Master -> A -> B -> C -> D
|
|-> Monolithic-Branch -> E -> F -> G -> H -> Rebase Master -> Submit as final
|
|-> SubBranchA -> Cherry E
|
|-> SubBranchB -> Cherry F & G
Dave Meehan
  • 3,133
  • 1
  • 17
  • 24

1 Answers1

0

What will happen when the maintainers merge any of the sub-PRs and/or the monolithic PR, and what will happen to my local if I rebase from master when some/all of the sub-PRs have been merged, prior to my mono-PR being submitted as final?

When the maintainers merge your sub-PRs, you will need to rebase your Monolithinc-Branch on the updated master branch. This will eliminate some of the commits along your feature branch (and depending on the nature of your changes may require resolving some merge conflicts).

If your Monolithic-Branch merges before the sub-PRs, then the sub-PR's can be discarded, because the changes are already incorporated in your feature branch.

Lastly, if you have the time and you're interested in alternate workflows, I suggest taking a look at stacked git, which I find tremendously useful for managing exactly this sort of situation (where you have a stack of dependent commits).

larsks
  • 277,717
  • 41
  • 399
  • 399