Re: [RFC] patch's default backup behavior

Kyle Evans <[email protected]>
Newsgroups gmane.os.freebsd.devel.hackers,gmane.os.freebsd.architechture,gmane.os.freebsd.devel.ports
Message-ID <CACNAnaFi2Ee5M5bX=FoaV-h=nC0kVrpEBqzuyG8SQhJeqkto3g@mail.gmail.com>
On Fri, Apr 8, 2022 at 10:41 PM Warner Losh <[email protected]> wrote:
>
>
>
> On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <[email protected]> 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?
>

Yeah, the current behavior is actually represented by the `-b` flag.
With the new behavior, we'd specifically implement
`--backup-if-mismatch` (a nop from the beginning),
`--no-backup-if-mismatch` (turn off backups, equivalent to `-V none`
but "lighter" in that it won't override -b/-V) and we'd leave existing
flags otherwise alone.

> I like the Idea.
>
> Warner
>
>> Thanks,
>>
>> Kyle Evans
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.