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

[Patrick Steinhardt <ps@pks.im>]

On Fri, Feb 06, 2026 at 08:25:42AM -0800, Junio C Hamano wrote:
> 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).

Sounds sensible.

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