Contributor's actions after rejected pull request

Question

Imagine, there is an open-source project with a Maintainer and a Contributor. Both of them have theirs repos exported to some repository hosting (github, bitbucket, sourceforge --- whatever, but they are public).

Imagine further, Contributor did several commits, pushed them into his repo and sent pull-request to the Maintainer. Maintainer did review, made several comments about commits (fix this, fix that, simplify there, blah-blah-blah) and rejected the pull-request. Note:

1. For Contributor it's obvious that it's better to just fix patches/commits than rewriting from scratch.

2. Please consider situation, when there are many commits and fixes have to be scattered between them.

What should Contributor do in this situation before making next pull-request? Remove invalid repo, rewrite history and push new one? Make a fix commit into current one?

May Maintainer demand, that incoming history should be clean? I.e. is it technically simple enough to do?

Answer 1

Most of the time, you simply incorporate the changes into a new commit which gets appended to the same pull request. Primarily this is so you don't lose the review history when the fixes are reviewed. Reviewers will want to be able to easily compare your original submission to the fixed version. If the maintainer wants a "clean history" (by definition an inaccurate history, but that's a rant for another time), then they will usually squash your pull request when they accept it.

However, some maintainers may specifically ask you to clean up the history. In that case, a contributor should do what they ask, which may necessitate a new pull request, depending on the tool you're using. If you are submitting several dependent features at once, you may want to keep them in separate branches locally to make clean up like this easier.