Date: Sun, 10 Apr 2022 22:47:38 +0200 From: Joerg Sonnenberger <joerg@bec.de> To: freebsd-hackers@freebsd.org Subject: Re: [RFC] patch's default backup behavior Message-ID: <YlNCamBCGutt6Kb5@bec.de> In-Reply-To: <CACNAnaHzTVA-S9dZJN48YO2RhJ5hDuK=eqUFakptjwRKNXD3%2BA@mail.gmail.com> References: <CACNAnaGTZSGKP=FKT1deAjJ0W=Q5Ezqf0ZinC2ydDzUksk%2BFtw@mail.gmail.com> <YlIwJWLuIQ6g6fp0@bec.de> <CACNAnaHzTVA-S9dZJN48YO2RhJ5hDuK=eqUFakptjwRKNXD3%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Sun, Apr 10, 2022 at 09:43:41AM -0500 schrieb Kyle Evans: > On Sat, Apr 9, 2022 at 8:17 PM Joerg Sonnenberger <joerg@bec.de> wrote: > > > > 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. > > > > To be clear, when you say 'tooling' here, are you referring to pkgsrc > tooling or random third-party tooling being used as, e.g., build > dependencies? pkgsrc tooling, e.g. managing category/package/patches. Similar questions might exist for FreeBSD ports. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YlNCamBCGutt6Kb5>