Date: Sun, 10 Apr 2022 12:33:25 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: Kyle Evans <kevans@freebsd.org>, freebsd-arch@freebsd.org Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org> Subject: Re: [RFC] patch's default backup behavior Message-ID: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> In-Reply-To: <CACNAnaGTZSGKP=FKT1deAjJ0W=Q5Ezqf0ZinC2ydDzUksk%2BFtw@mail.gmail.com> References: <CACNAnaGTZSGKP=FKT1deAjJ0W=Q5Ezqf0ZinC2ydDzUksk%2BFtw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[resending from hopefully subscribed address that it makes it to some of the lists] Am 09.04.22 um 05:25 schrieb Kyle Evans: > Hello! > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > where a backup is created for every file patched. > > 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? Cross-posted this to a couple of > different lists to try and hit the largest number of stakeholders in > patch(1) behavior. > > Thanks, > > Kyle Evans > Kyle, you would discard the original reference for gendiff or "make makepatch" in ports, that would make patch - edit - regenerate-patch cycles require extra efforts, and if that extra effort is only remembering patch's -b option, but if we do it consistently for FreeBSD 14 and announce it in due time beforehand, fine. Certainly worthy of release notes. I personally also dislike and advise against "magic" and if-then behavior. It makes documentation less concise, it makes tool behavior more complex to judge, and from people who script a test-based approach, this bears potential for confusion, astonishment and other effects, because behavior as to when we get .orig files gets *apparently* inconsistent, and may send people who have not read the entire manual to the letter on detours finding out why they sometimes get .orig, or worse, when developing patches, and interaction with other tools might surprise people, too. IF we are to change policy, my vote is to ALWAYS leave the .orig files away and not only write them if we also write .rej files. I explicitly dislike the GNU behavior, which seems geared for interactive use rather than scripting. I checked POSIX 2018, apparently the backup files (.orig) are only required if -b is given, so omitting them would seem fine to me, and the rationale section suggests that for consistency with other utilities, the default would be to NOT save .orig file, but the -b option can be used to request them being written (but then consistently on all files not just those without rejects - also because there is no working patch -R for ed-style diffs.).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9f6f6d16-8e2e-b91d-9ba1-b2cf13270020>