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

Patrick Steinhardt [off-list ref] writes:

On Thu, Feb 05, 2026 at 07:50:55AM -0800, Junio C Hamano wrote:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

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.