Felipe Contreras wrote: > Any sensible reviewer would be context aware, notice that this > is a contrib patch, and focus on behavioral changes, notice the > mistake I made, and point that *one* of the changes was changing the > behavior, at which point I would agree and reroll either without that > change, or with the change in a separate commit (which I don't want to > do right now). The maintainer (you), wouldn't even have to reply at > all. Personally, I think it is the job of the submitter to provide a really helpful commit message and widen his review audience. If I'm hitting the git mailing list with my patches, I try to make sure that nearly everyone on the list can understand what I've done and potentially review it. Why else would I want to hit their inboxes with my patches? Here's my solution to the problem: maintain your project outside git.git and merge changes in every couple of months or so with a simple email containing a pull URL, addressing Junio. If Junio trusts you enough to put the changes you send into contrib/ after a cursory glance, we're done. Start a separate mailing list for your project/ accept GitHub pull requests via which contributors can send you changes. No more fuss or drama on the git list about this. You can be as stubborn as you want, and we go back to our lives. Everyone wins. If you want to submit patches to other parts of git, you seriously need to change your ways. Let's deal with that problem when it arises next. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html