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

On Fri, Feb 06, 2026 at 08:25:42AM -0800, Junio C Hamano wrote:

Patrick Steinhardt [off-list ref] writes:

quoted

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

Sounds sensible.

quoted

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.

Yeah, we certainly don't want that. The remark was rather about a reader
not being able to discern those two cases (does or does not end in a
newline) anymore. Or would they?

Patrick