René Scharfe <l.s.r@xxxxxx> writes:
> $ diff --ignore-blank-lines -u 1 2
> --- 1 2020-11-02 18:11:04.618133008 +0100
> +++ 2 2020-11-02 18:11:04.618133008 +0100
> @@ -1,4 +1,4 @@
> aaa
> bbb
> -ccc
>
> +ccc
> $ diff --ignore-blank-lines -u 2 1
>
> This matches your results. That the order makes a difference is a bit
> odd. Both are valid diffs of the inputs and neither one changes blank
> lines, though, so it doesn't look like a bug.
Interesting. If "diff" happens to pick the line with "ccc" on it as
the unchanging pair of lines between the preimage and the postimage,
then another "valid diff of the inputs" would look like this:
aaa
bbb
+
ccc
-
What such a patch would change consists only of blank lines. It is
reasonable to expect "--ignore-blank-lines" would turn it into a
no-op, provided if "diff" picks "ccc" as the matching line.
But if "diff" picks that the blank line at the end of the original
file as unchanged line, then we'll see the diff quoted in the first
part of this message. And that patch does not change any blank
lines, so it is unreasonable to expect "--ignore-blank-lines" to
turn it into a no-op.
So it all depends on which matching pair "diff" first picks, before
the "are all the lines changed by the hunk blank ones?" kicks in.
One could argue that "diff" should work hard to enumerate all the
possible combinations (we just saw two possible combinations above)
to find one that allows "--ignore-blank-lines" to produce an empty
patch, but I am not sure it is a sensible thing to do.
> $ git diff --ignore-blank-lines 1 2
> $ git diff --ignore-blank-lines 2 1
> $ git --version
> git version 2.29.2
>
> This matches your expectation, but not your results. Which version do
> you use?
>
> René
