Question

Scenario

If User X maintains a repo, and User A submits a pull-request, I want, as User B to suggest cleanup or additional features on top of that pull-request.

What I'm doing

The way I'm doing it is fetch User A's repo and feature branch, update the code and submit a stand alone pull-request to User X.

Question

But the above feels a little douchebaggy and wrong. Is there a better way?

Was it helpful?

Solution

You can make a separate pull-request to UserA's feature branch. If he accepts it, your commits will be added to the original pull-request.

You can also refer to the original pull request in the new one so it shows up in a comment on Github.

If he doesn't accept the pull request, go the douchebaggy way. His commits will still show up as his own, so it doesn't matter much.

OTHER TIPS

The best way is to not use pull requests at all. That's why the Git project doesn't use pull requests for development, instead, each patch series is sent to the mailing list, where it's easy to review each patch, then the original author fixes the issues and sends a re-roll of the series, which receives more reviews and so on. It's not unusual for each patch series to re-roll multiple times.

That's the main reason Linus Torvalds didn't like the whole GitHub approach.

That being said, you can review patches in Github, and request the original author to send another pull-request.

As a last resort, what I do is that I manually add the User A remote to my local repo, fetch, and fix the commits myself, adding an appropriate comment, or adding new separate commits, and then merge my local branch, not the remote one.

2017 update:

Github now allows pushing changes to the branch the pull request was made from, if the commiter allows it.

When creating a pull request there is now an option to: "Allow edits from maintainers". It's checked by default.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top