On Thu, Oct 13 2022, Junio C Hamano wrote: > Æ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. 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!
