From: Patrick Steinhardt Date: Fri, 06 Feb 2026 16:58:01 GMT Subject: Re: [PATCH] whitespace: symbolic links usually lack LF at the end Message-ID: In-Reply-To: On Fri, Feb 06, 2026 at 08:25:42AM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > On Thu, Feb 05, 2026 at 07:50:55AM -0800, Junio C Hamano wrote: > >> Patrick Steinhardt 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