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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2026, 16:25 UTC
Message-ID: <xmqqv7g9hm9l.fsf@gitster.g>
In-Reply-To: <aYWKyOIMPLiDxqnj@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 15 quoted lines

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