On Sun, Jul 03, 2022 at 09:35:17PM +1000, Mark Jamsek wrote:
> I'm not sure how I feel about this being the default though. I admit,
> it's nice not having failed patches, but as far as I'm aware, no other
> patch implementations do it by default so it might fail the Rule of
> Least Surprise.

What is the reason why other implementations do not enable this
feature by default? I cannot think of any, other than that it matches
how Larry's patch(1) works. Could you find out the rationale which
inspired Fossil to make this behaviour opt-in?

A rationale for svn patch (which uses an opt-in --ignore-whitespace
flag) was given in the log message of https://svn.apache.org/r934569
"""
Since this matching is not as restrictive as the usual one, there's a
risk of erroneus behaviour, i.e. matching a patch with all leading
spaces removed makes it impossible to distinguish between a context line
and some other line, intended to be ignored. 
"""

I don't think the failure mode described there matters in practice.
Hunk headers tell the parser how many lines to expect while parsing
the hunk. Valid hunks do not contain any unrelated lines, and any
hunks which do would fail to apply regardless of whitespace issues.

In hindsight, I should probably have brought up the same question for
'svn patch' when r934569 was committed. But by now it is too late for
changing the default behaviour of 'svn patch'.