Say you own a project and have some idea of how you want code and commits to be structured. In comes a pull request that doesn't live up to that. No problem. Sometimes you can ask them to correct a few things and merge away, but at other times there will be too many things and, well, you don't want to come off as a person that is hard to deal with.
What do you consider appropriate etiquette regarding changing their code and/or commit messages and doing a manual merge where you pull down their branch and go to town? How this is usually done is that they will be the author of the commit and you will be the committer (Git feature), but a lot of the code might be yours, and the commit message might be yours as well. Basically, you are changing their code and wording, but they retain the main credit for the work and you stand merely as the committer of the code.
I have seen this happen on a several popular projects, and I can understand why. My question is: Is the author/committer feature of Git enough to indicate that the person might not have written all the code or even written the commit message? What I fear is that the code, or even the commit message, ends up being something that they would not want out there under their name when all is said and done, and that this way of managing a project will scare people away.
So I'm curious about people's take on this, because I've seen it happen on several projects, and there's even been blog posts here on HN about this practice.
However, if its a significant amount of code, it would be considerate that the project maintainer to merge the changes first, then modify in a subsequent commit. That my two cents.