let's not complain about harmless patch-apply failures

On Tue, Jan 16, 2018 at 4:04 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> At Mon, 15 Jan 2018 21:45:34 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <26718(dot)1516070734(at)sss(dot)pgh(dot)pa(dot)us>
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> > Since the "Stripping trailing CRs from patch" message is totally
>> > harmless, I'm not sure why you should need to devote any effort to
>> > avoiding it. Anyone who gets it should just ignore it.
>
> I know that and totally agree to Robert but still I wonder why
> (and am annoyed by) I sometimes receive such complain or even an
> accusation that I sent an out-of-the-convention patch and I was
> afraid that it is not actually common.

I've seen that before as well.

I have also noticed people complaining about patches that apply "with
offsets", which also seems like needless nitpicking. If the offsets
are large and the patch has been sitting around for a long time,
there's a small chance it could be applying to the wrong place, but
that is extremely rare. Most patches have small offsets, just a few
lines, and there is no problem. Complaining about the offsets, on the
other hand, is unhelpful: it not only forces the patch author to
update the patch for no good reason, but it clutters the mailing list
with useless traffic that everyone else has to ignore.

I think we should have a firm policy that if patch -p1 can apply your
patch, your patch is sufficiently well-formatted. If someone wants
the result as a context diff, a unified diff, with one kind of line
endings vs. another, or whatever, they can apply the patch locally and
use whatever tools they like to get a diff in the format they prefer.

When posting large patch stacks, 'git format-patch' is nice because it
lets you give a sequence number and a commit message to each patch in
a sensible way. I recommend it, but I don't think we should insist on
it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company