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

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

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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to