Re: About git reporting missing newline for symlinks

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Oct 13 2022, Junio C Hamano wrote:

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

That's really informative, thanks.

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

Clearly it confused the initial reporter upthread :) I'm not going to
pursue it, but it seems to me that we're being sloppy here in including
a message that makes more sense for a normal diff when we could consider
the mode(s) involved, as it's not abnormal for a filename to be missing
a trailing "\n" (having a "\n" being the odd case).

Anyway, I'm not going to pursue changing the message, but maybe if
someone else is interested the above compatibility notes would be
valuable, thanks!