Re: [RFC] patch's default backup behavior

On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree <matthias.andree@gmx.de> wrote:
>
> [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.
>

Arguably, `make patch` should be using the `-b` option even today to
be portable across different patch implementations. Yes, we have our
own patch with our own behavior that we can rely on, but I'm
personally a fan of not tying ourselves and, perhaps more importantly,
others (downstreams) into one behavior when we can trivially wire it
down.

> 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.
>

There are certainly trade-offs -- with the GNU behavior, you can
instead quickly use the presence of an .orig file to know that you may
need to sanity check the result and tooling can key off the same
rather than checking patch(1) output for words like 'fuzz'. fuzz has
bitten people before, it will bite people again.

I'm not so sure that the scenario you write about will really happen.
GNU patch has done this for many years, and I haven't seen such a
proliferation of confusion. If anything, I see more confusion in
practice from BSD patch's default differing from both the much more
common GNU behavior and also from POSIX-specified behavior.

> 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.
>

re: interactive use, I think that's an entirely separate debate, even.
:-) My personal opinion is that defaults *should* be geared more for
interactive use, and scripts should be (+ able to be) entirely
explicit about the behavior they want. This is a general opinion, not
just with patch. If you solidify script usage with flags, then we can
be a bit more fluid so that tooling can adapt to the ever-changing
user landscape. Obviously you can't reliably predict potential for
future behavior changes, though there are some obvious candidates like
this one where the difference in defaults between us and other
implementations are well-known.

> 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.).

I'd actually be OK with that, too, to an extent.

Thanks,

Kyle Evans