Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> In apply.c's parse_fragment() we seem to only care that we find a
> "\"-line that's at least the length of "\ No newline...".
If I recall correctly, this was done very much on purpose back in
2005 on top of what I and Linus did originally (which was specific
to "No newline" written in C locale). Because the input from "git
apply" may not necessarily be the output from "git diff", and in the
older days, "git diff" spawned platform "diff" to show diff, it would
have been subject to l10n.
With GNU diff, I can do
$ echo -n one >/var/tmp/1; echo -n two >/var/tmp/2
$ LC_ALL=ja_JP.utf8 diff -u /var/tmp/[12]
--- /var/tmp/1 2022-10-13 08:40:55.393209930 -0700
+++ /var/tmp/2 2022-10-13 08:40:59.269538397 -0700
@@ -1 +1 @@
-one
\ ファイル末尾に改行がありません
+two
\ ファイル末尾に改行がありません
As it does not consider a file that ends with an incomplete line a
text file [*], I do not think POSIX says anything about lines that
begin with "\" in the "diff" output, but I would be surprised if GNU
patch (or anybody else's, for that matter) did not ignore text on
the line, because all of them must be able to parse the above
output.
> I wonder what (if any) compatibility issues we'd have if we emitted
> e.g.:
>
> \ The filename pointed to by the symlink does not end in a newline
While I do not think it would break anybody, I doubt it would give
us much value. One line above that output is a line that any user,
who is vaguely familiar with the contents being compared, can
recognize as giving a pathname, the contents of the symbolic link.
[References]
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_83
