Re: About git reporting missing newline for symlinks

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2022, 16:02 UTC
Message-ID: <xmqq35briuel.fsf@gitster.g>
In-Reply-To: <221013.86o7uflvcv.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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