12

I'm the owner of the code in github and responsible of merging PRs in the main upper stream. I have two different PRs from different two contributers which have conflicts in some files. Who is responsible in resolving conflicts in the both PRs? shall I reject one of them?

  • 6
    I would merge the earlier one and then ask the latter to rebase against master. – S.S. Anne Dec 16 '19 at 21:06
15

That's a tricky question for the maintainers / core devs to answer and there cannot be "the one correct answer" as it depends highly on how that particular community works and how the people talk to each other.

Factors to consider are the type of contribution (bug fix, feature extension, new feature), quality of the contributions, the need and urgency to have one or both merged into master, and the time the individual people (patch authors, core devs) can and likely would be willing to spend on the issues. Either way it's good manners to explain the situation to the involved PR authors.

Whatever approach you take, you will need to decide which PR to merge first:

  • is one PR clearly more important or beneficial than the other? IMHO: bug fix > feature enhancement / new feature
  • is one of the PR authors more communicative and approachable? Explain the situation to him and ask him to rebase his/her PR on top of the other. If so agreed, merge the other PR and wait for an update to the second.
  • can you spend the time yourself right now? Then just do that, if you want it done quickly. But still explain why you did so to the PR authors in the closing message or a comment. They might want to have done the necessary changes themselves in another way.
| improve this answer | |
  • Yeah I'd avoid merging somebody else's contributions yourself as you may not sufficiently understand the nuances. Otherwise a good answer though... – Lightness Races in Orbit Dec 17 '19 at 12:21
  • 1
    @LightnessRaceswithMonica in my understanding how it works, how it works in the project I participate and how likely many somewhat larger projects work: as maintainer who has merge rights you somewhat constantly review and merge other people's contributions... so you should know what the code does. Yet usually also an updated PR (by whoever) needs approving review again by at least one person with review rights. Smaller projects might have less strict review requirements and also on who can merge. – planetmaker Dec 17 '19 at 20:06
  • To be honest, I suspected that would be your response, and (depending on the project, as you say) it's a fair one. :) – Lightness Races in Orbit Dec 18 '19 at 0:30
3

As @planetmaker pointed out, every one has their opinions. But weighing in my $.02, it's usually first raised first merged. So, whoever raised it later has to work on merging it in. The reason for doing this is simply because the the owner is just a middleman to make sure of code quality. So simulating the behaviour of git, usually the one who pushes after the last commit has to fix the conflict. Ofcourse, exceptions can be made when there's a bug fix that's needed ASAP and so on.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.