Re: [PATCH] whitespace: symbolic links usually lack LF at the end

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Thu, Feb 05, 2026 at 07:50:55AM -0800, Junio C Hamano wrote:
>> Patrick Steinhardt <ps@pks.im> writes:
>> 
>> > I'd suggest that we only disable this check in case either:
>> >
>> >   - One side doesn't exist, the other is a symbolic link.
>> >
>> >   - Both sides are a symbolic link.
>> 
>> Hmm.  That is indeed a thoguht.  But we do not want to complain in
>> text-to-symlink transition that postimage lacks the terminating LF,
>> so the above rules may be a good start but will need further
>> tweaking, I am afraid.
>
> Ah, right. Only the other way around, when converting from LF to text.

I've decided to use the "disable only when the side that appears
postimage (taking --reverse option into account) is a symbolic link"
rule.

Strictly speaking, "diff" (but not "apply") has wsErrorHighlight
feature where it can be configured to complain about whitespace
glitches in both pre- and postimage, so it is technically not
sufficient, but it is not worth supporting diff.wsErrorHighlight
that is set to anything but "new" (or "default" which is its
synonym).

> Eh, I didn't mean symrefs here, but symbolic links :) Tools like ln(1)
> seem to strip trailing newlines, but if you try hard enough you'll
> probably be able to create symlinks that have a target with trailing
> newline.

Yes, as you can create a file whose name contains a newline, a name
that ends in a newline is a valid filename that "ln -s" may want to
support.  I am reasonably sure that we do not want to flag such a
symbolic link as whitespace damaged.