Re: [RFC] patch's default backup behavior
- Reply: Joerg Sonnenberger : "Re: [RFC] patch's default backup behavior"
- In reply to: Joerg Sonnenberger : "Re: [RFC] patch's default backup behavior"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 10 Apr 2022 14:43:41 UTC
On Sat, Apr 9, 2022 at 8:17 PM Joerg Sonnenberger <email@example.com> 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?