From nobody Sun Apr 10 01:17:25 2022
X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2B3671A995C5
	for <freebsd-hackers@mlmmj.nyi.freebsd.org>; Sun, 10 Apr 2022 01:17:30 +0000 (UTC)
	(envelope-from joerg@bec.de)
Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [IPv6:2001:4b98:dc4:8::232])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbYxj080Nz3lZS
	for <freebsd-hackers@freebsd.org>; Sun, 10 Apr 2022 01:17:28 +0000 (UTC)
	(envelope-from joerg@bec.de)
Received: (Authenticated sender: joerg@bec.de)
	by mail.gandi.net (Postfix) with ESMTPSA id A334C200004
	for <freebsd-hackers@freebsd.org>; Sun, 10 Apr 2022 01:17:27 +0000 (UTC)
Date: Sun, 10 Apr 2022 03:17:25 +0200
From: Joerg Sonnenberger <joerg@bec.de>
To: freebsd-hackers@freebsd.org
Subject: Re: [RFC] patch's default backup behavior
Message-ID: <YlIwJWLuIQ6g6fp0@bec.de>
Mail-Followup-To: freebsd-hackers@freebsd.org
References: <CACNAnaGTZSGKP=FKT1deAjJ0W=Q5Ezqf0ZinC2ydDzUksk+Ftw@mail.gmail.com>
List-Id: Technical discussions relating to FreeBSD <freebsd-hackers.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-hackers
List-Help: <mailto:freebsd-hackers+help@freebsd.org>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Subscribe: <mailto:freebsd-hackers+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-hackers+unsubscribe@freebsd.org>
Sender: owner-freebsd-hackers@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACNAnaGTZSGKP=FKT1deAjJ0W=Q5Ezqf0ZinC2ydDzUksk+Ftw@mail.gmail.com>
X-Rspamd-Queue-Id: 4KbYxj080Nz3lZS
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 2001:4b98:dc4:8::232) smtp.mailfrom=joerg@bec.de
X-Spamd-Result: default: False [1.36 / 15.00];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[joerg];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-0.54)[-0.540];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_SPAM_MEDIUM(0.97)[0.972];
	 DMARC_NA(0.00)[bec.de];
	 NEURAL_SPAM_SHORT(0.13)[0.132];
	 MLMMJ_DEST(0.00)[freebsd-hackers];
	 R_SPF_NA(0.00)[no SPF record];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::232:from]
X-ThisMailContainsUnwantedMimeParts: N

Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans:
> I'd like to test the waters on switching this to the GNU behavior,
> which feels a whole lot more reasonable. Notably, they'll only create
> backup files if a mismatch was detected (presumably this means either
> a hunk needed fuzz or a hunk outright failed). This yields far fewer
> backup files in the ideal scenario (context entirely matches), while
> still leaving backup files when it's sensible (base file changed and
> we might want to regenerate the patch).
> 
> Thoughts / comments / concerns?

Personally, I'm more often annoyed by the GNU behavior than not.
Especially when working on pkgsrc, the GNU behavior of
sometimes-not-creating-backups actually breaks tooling. I also consider
the rationale somewhat fishy as tools like sed have historically not
operated in-place.

Joerg