How to distinguish between commits in stacked pull requests-CodePudding

I am working on building out the documentation site on a github repo, which involves a lot of file changes and new files. To simplify the review, I wanted to break up the big feature branch into smaller PRs. I was just trying to figure out how to practically manage this.

I am following this post, that shows how to break up a large pull request into stacked pull requests. The idea is to checkout a branch new_feature from master, then implement some changes and open a PR against this branch. Next I checkout a new branch new_feature_p2 starting from new_feature and make some more changes and create a PR against new_feature_p2.

The question is, when I go to github and I try to create the PR for new_feature_p2, I can still see the commit for the original new_feature branch. I am not sure if that is okay, or if I need to change something so that I don't recommit the same files in the second PR.

Note that I forked the original repository, so I am submitting changes off of the fork. Will those common commits from PR1 and PR2 disappear once PR1 is approved? Then PR2 will just go in without any changes to the PR1 files?

Or is there some better way to handle this process.

CodePudding user response：

The question is, when I go to github and I try to create the PR for new_feature_p2, I can still see the commit for the original new_feature branch

Because you forgot to repoint the second PR's target branch (the one you're merging into) at the original new_feature branch.

Okay, that's not quite accurate, because we're talking about how the second PR is seen back on the original repo. The answer there, I think, is that your intuition here is correct:

Will those common commits from PR1 and PR2 disappear once PR1 is approved? Then PR2 will just go in without any changes to the PR1 files?

Yes. What's shown in PR2 is simply a calculated diff between this branch and the main branch. Once PR1 is merged into the main branch on the original repo, things that are present in PR2 merely because they were present in PR1 will no longer be different between PR2 and main, and so PR2 will look the right way.

As I say in my comment, perhaps the most helpful strategy for the owners of the original repo would be for you to go ahead and divide your work into branches but don't even submit the next PR until the prior PR has been merged. That way, the overlords of the original repo always see only the minimum material in each PR, which was your goal all along.