Re: About git reporting missing newline for symlinks
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Oct 13, 2022, 13:11 UTC
- Message-ID
- <221013.86o7uflvcv.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <xmqq7d14k9uh.fsf@gitster.g>
On Wed, Oct 12 2022, Junio C Hamano wrote:
Show 26 quoted lines
> Ignacio Taranto <ignacio.taranto@eclypsium.com> writes: > >> So, both git diff and git show display "\ No newline at end of file" >> for symlinks. >> >> I think this is related to how Git renders diffs, IMO it shouldn't >> display a warning about newlines for symlinks. >> >> Am I making any sense here? > > Yes, but not really. > > It is not "warning" at all. The users want to know when compared > contents do or do not end with an incomplete line at the end, and > the "\ No newline" is the diff's way to give that single bit of > information to us. > > And the contents of a symbolic link typically is a single incomplete > line, so it is expected to see "\ No newline" when comparing them. > > This is important as "git diff | git -C ../some/where/else apply" > should be able to recreate the change in the current repository > (which may have change to or addition of a symbolic link) in the > other repository, and "git apply" on the receiving end must be able > to tell that the symbolic link it needs to create in the other > repository must not have an extra LF at the end.
In apply.c's parse_fragment() we seem to only care that we find a "\"-line that's at least the length of "\ No newline...".
I wonder what (if any) compatibility issues we'd have if we emitted e.g.:
\ The filename pointed to by the symlink does not end in a newline