Date: Fri, 8 Apr 2022 21:41:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Kyle Evans <kevans@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org> Subject: Re: [RFC] patch's default backup behavior Message-ID: <CANCZdfopEmCaszMx%2B%2B15irhZLvZz=aQrG5YStyMzVxU=8EFQvg@mail.gmail.com> 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
[-- Attachment #1 --] On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <kevans@freebsd.org> wrote: > 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. > Could one select the old behavior? Or would it just be a change? A new -V value? I like the Idea. Warner Thanks, > > Kyle Evans > > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <<a href="mailto:kevans@freebsd.org" target="_blank" rel="noreferrer">kevans@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br> <br> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups,<br> where a backup is created for every file patched.<br> <br> I'd like to test the waters on switching this to the GNU behavior,<br> which feels a whole lot more reasonable. Notably, they'll only create<br> backup files if a mismatch was detected (presumably this means either<br> a hunk needed fuzz or a hunk outright failed). This yields far fewer<br> backup files in the ideal scenario (context entirely matches), while<br> still leaving backup files when it's sensible (base file changed and<br> we might want to regenerate the patch).<br> <br> Thoughts / comments / concerns? Cross-posted this to a couple of<br> different lists to try and hit the largest number of stakeholders in<br> patch(1) behavior.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Could one select the old behavior? Or would it just be a change? A new -V value?</div><div dir="auto"><br></div><div dir="auto">I like the Idea. </div><div dir="auto"><br></div><div dir="auto">Warner </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks,<br> <br> Kyle Evans<br> <br> </blockquote></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfopEmCaszMx%2B%2B15irhZLvZz=aQrG5YStyMzVxU=8EFQvg>