I know about using branches for multiple pull requests, that's fine.
But what about this scenario:
I've found two conflicting sets of advice (but perhaps the dependency on B is different)
Advice from GitHub seems to say C should be applied against A:
Changing the base repository changes who is notified of the pull request. Everyone that can push to the base repository will receive an email notification and see the new pull request in their dashboard the next time they sign in.
This would seem to apply in this case for two reasons:
But this answer on StackOverflow says the opposite, that C should be applied against B. Note that his scenario is a->b->c->d->e
, vs. my simpler A->B->C
.
Make another request. For the base, type in the commit number of C, and for the head, put E (yours/master).
This is equivalent to B->C range in my scenario.
To me, both arguments make some amount of sense. Which is correct?
I'm guessing that the answer is "it depends...", but I'd really appreciate the walkthrough. It feels like there's at least three issues here:
Thoughts???
It is a communication problem, more than a Git issue.
I prefer making separate PR, as their intent and scope differs.
But, in the PR message, one must clearly states if that PR is suppose to supersede another PR.
That way, the original repo project manager can try those different PR separately, gauging their effects, and select the appropriate one.
He can then ask initial contributors to redo their PR (on their same branch) based on the work of the PR he or she finally selected.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With