{"thread":{"id":"58616","subject":"About git reporting missing newline for symlinks","startedAt":"2022-10-12T21:17:29Z","lastAt":"2022-10-13T22:01:44Z","messageCount":15,"participants":["Ignacio Taranto","Junio C Hamano","brian m. carlson","Taylor Blau","Ævar Arnfjörð Bjarmason","Philip Oakley","Erik Cervin Edin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"464772","messageId":"CAAHd=zcrU3VJro1R3xDj3hmqGXZHUA6rHuDFxwhF5aewNvA8xQ@mail.gmail.com","threadId":"58616","inReplyTo":null,"subject":"About git reporting missing newline for symlinks","fromName":"Ignacio Taranto","fromEmail":"ignacio.taranto@eclypsium.com","sentAt":"2022-10-12T21:17:04Z","receivedAt":"2022-10-12T21:17:29Z","isPatch":false,"sender":{"key":"ignacio.taranto@eclypsium.com","avatar":null},"body":"So, both git diff and git show display \"\\ No newline at end of file\"\nfor symlinks.\n\nI think this is related to how Git renders diffs, IMO it shouldn't\ndisplay a warning about\nnewlines for symlinks.\n\nAm I making any sense here?\n"},{"id":"464775","messageId":"xmqq7d14k9uh.fsf@gitster.g","threadId":"58616","inReplyTo":"CAAHd=zcrU3VJro1R3xDj3hmqGXZHUA6rHuDFxwhF5aewNvA8xQ@mail.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-12T21:31:18Z","receivedAt":"2022-10-12T21:31:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ignacio Taranto <ignacio.taranto@eclypsium.com> writes:\n\n> So, both git diff and git show display \"\\ No newline at end of file\"\n> for symlinks.\n>\n> I think this is related to how Git renders diffs, IMO it shouldn't\n> display a warning about newlines for symlinks.\n>\n> Am I making any sense here?\n\nYes, but not really.\n\nIt is not \"warning\" at all.  The users want to know when compared\ncontents do or do not end with an incomplete line at the end, and\nthe \"\\ No newline\" is the diff's way to give that single bit of\ninformation to us.\n\nAnd the contents of a symbolic link typically is a single incomplete\nline, so it is expected to see \"\\ No newline\" when comparing them.\n\nThis is important as \"git diff | git -C ../some/where/else apply\"\nshould be able to recreate the change in the current repository\n(which may have change to or addition of a symbolic link) in the\nother repository, and \"git apply\" on the receiving end must be able\nto tell that the symbolic link it needs to create in the other\nrepository must not have an extra LF at the end.\n\n"},{"id":"464776","messageId":"Y0cyX8Ggp+dkgAjX@tapette.crustytoothpaste.net","threadId":"58616","inReplyTo":"CAAHd=zcrU3VJro1R3xDj3hmqGXZHUA6rHuDFxwhF5aewNvA8xQ@mail.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-10-12T21:32:15Z","receivedAt":"2022-10-12T21:32:48Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-10-12 at 21:17:04, Ignacio Taranto wrote:\n> So, both git diff and git show display \"\\ No newline at end of file\"\n> for symlinks.\n> \n> I think this is related to how Git renders diffs, IMO it shouldn't\n> display a warning about\n> newlines for symlinks.\n> \n> Am I making any sense here?\n\nWhat Git shows for a symlink is the destination of the symlink.  On\nUnix systems other than macOS, path names may contain any byte other\nthan NUL, including a newline.\n\nWhile it obviously is not a good practice to include newlines in your\npaths, it is possible, and Git would not be able to round-trip symlinks\nwhere the final character of the destination is a newline if we didn't\nhandle trailing newlines properly.  As a result, we're not likely to\nchange things here because it's required for correctness.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"464777","messageId":"xmqq35bsk9og.fsf@gitster.g","threadId":"58616","inReplyTo":"Y0cyX8Ggp+dkgAjX@tapette.crustytoothpaste.net","subject":"Re: About git reporting missing newline for symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-12T21:34:55Z","receivedAt":"2022-10-12T21:35:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> On 2022-10-12 at 21:17:04, Ignacio Taranto wrote:\n>> So, both git diff and git show display \"\\ No newline at end of file\"\n>> for symlinks.\n>> \n>> I think this is related to how Git renders diffs, IMO it shouldn't\n>> display a warning about\n>> newlines for symlinks.\n>> \n>> Am I making any sense here?\n>\n> What Git shows for a symlink is the destination of the symlink.  On\n> Unix systems other than macOS, path names may contain any byte other\n> than NUL, including a newline.\n>\n> While it obviously is not a good practice to include newlines in your\n> paths, it is possible, and Git would not be able to round-trip symlinks\n> where the final character of the destination is a newline if we didn't\n> handle trailing newlines properly.  As a result, we're not likely to\n> change things here because it's required for correctness.\n\nJust a fun thought experiment, but I wonder what would happen if a\nuser chooses to add .clean and .smudge filter that adds and strips\na LF at the end ;-)\n"},{"id":"464779","messageId":"Y0c0tDEDpV8fO6n/@tapette.crustytoothpaste.net","threadId":"58616","inReplyTo":"xmqq35bsk9og.fsf@gitster.g","subject":"Re: About git reporting missing newline for symlinks","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-10-12T21:42:12Z","receivedAt":"2022-10-12T21:42:18Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-10-12 at 21:34:55, Junio C Hamano wrote:\n> Just a fun thought experiment, but I wonder what would happen if a\n> user chooses to add .clean and .smudge filter that adds and strips\n> a LF at the end ;-)\n\nI don't believe those are invoked on symlinks, since I don't recall us\nhaving to handle symlinks in Git LFS, which works using a smudge and\nclean filter.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"464780","messageId":"CAAHd=zd2fRAiW4tZa-yCie3tGMzcmye-75_b1tcYtMTyf1Li2A@mail.gmail.com","threadId":"58616","inReplyTo":"xmqq7d14k9uh.fsf@gitster.g","subject":"Re: About git reporting missing newline for symlinks","fromName":"Ignacio Taranto","fromEmail":"ignacio.taranto@eclypsium.com","sentAt":"2022-10-12T21:42:44Z","receivedAt":"2022-10-12T21:43:04Z","isPatch":false,"sender":{"key":"ignacio.taranto@eclypsium.com","avatar":null},"body":"That was very well explained, thank you.\n\nThe problem seems to be that some people interpret this message as a\nreal warning since it's often a good practice to always end text files\nwith a newline (at least on *nix systems).\nOf course this doesn't apply to symlinks at all.\n\nOn Wed, Oct 12, 2022 at 6:31 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Ignacio Taranto <ignacio.taranto@eclypsium.com> writes:\n>\n> > So, both git diff and git show display \"\\ No newline at end of file\"\n> > for symlinks.\n> >\n> > I think this is related to how Git renders diffs, IMO it shouldn't\n> > display a warning about newlines for symlinks.\n> >\n> > Am I making any sense here?\n>\n> Yes, but not really.\n>\n> It is not \"warning\" at all.  The users want to know when compared\n> contents do or do not end with an incomplete line at the end, and\n> the \"\\ No newline\" is the diff's way to give that single bit of\n> information to us.\n>\n> And the contents of a symbolic link typically is a single incomplete\n> line, so it is expected to see \"\\ No newline\" when comparing them.\n>\n> This is important as \"git diff | git -C ../some/where/else apply\"\n> should be able to recreate the change in the current repository\n> (which may have change to or addition of a symbolic link) in the\n> other repository, and \"git apply\" on the receiving end must be able\n> to tell that the symbolic link it needs to create in the other\n> repository must not have an extra LF at the end.\n>\n"},{"id":"464791","messageId":"Y0d1Q/Vrgf5UZY+J@nand.local","threadId":"58616","inReplyTo":"Y0c0tDEDpV8fO6n/@tapette.crustytoothpaste.net","subject":"Re: About git reporting missing newline for symlinks","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-10-13T02:17:39Z","receivedAt":"2022-10-13T02:21:14Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 12, 2022 at 09:42:12PM +0000, brian m. carlson wrote:\n> On 2022-10-12 at 21:34:55, Junio C Hamano wrote:\n> > Just a fun thought experiment, but I wonder what would happen if a\n> > user chooses to add .clean and .smudge filter that adds and strips\n> > a LF at the end ;-)\n>\n> I don't believe those are invoked on symlinks, since I don't recall us\n> having to handle symlinks in Git LFS, which works using a smudge and\n> clean filter.\n\nThat is right. It matches my memory, at least, though it has been a very\nlong time since I've thought that hard about the clean / smudge code.\n\nThanks,\nTaylor\n"},{"id":"464827","messageId":"221013.86o7uflvcv.gmgdl@evledraar.gmail.com","threadId":"58616","inReplyTo":"xmqq7d14k9uh.fsf@gitster.g","subject":"Re: About git reporting missing newline for symlinks","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-10-13T13:11:49Z","receivedAt":"2022-10-13T13:13:45Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Oct 12 2022, Junio C Hamano wrote:\n\n> Ignacio Taranto <ignacio.taranto@eclypsium.com> writes:\n>\n>> So, both git diff and git show display \"\\ No newline at end of file\"\n>> for symlinks.\n>>\n>> I think this is related to how Git renders diffs, IMO it shouldn't\n>> display a warning about newlines for symlinks.\n>>\n>> Am I making any sense here?\n>\n> Yes, but not really.\n>\n> It is not \"warning\" at all.  The users want to know when compared\n> contents do or do not end with an incomplete line at the end, and\n> the \"\\ No newline\" is the diff's way to give that single bit of\n> information to us.\n>\n> And the contents of a symbolic link typically is a single incomplete\n> line, so it is expected to see \"\\ No newline\" when comparing them.\n>\n> This is important as \"git diff | git -C ../some/where/else apply\"\n> should be able to recreate the change in the current repository\n> (which may have change to or addition of a symbolic link) in the\n> other repository, and \"git apply\" on the receiving end must be able\n> to tell that the symbolic link it needs to create in the other\n> repository must not have an extra LF at the end.\n\nIn apply.c's parse_fragment() we seem to only care that we find a\n\"\\\"-line that's at least the length of \"\\ No newline...\".\n\nI wonder what (if any) compatibility issues we'd have if we emitted\ne.g.:\n\n\t\\ The filename pointed to by the symlink does not end in a newline\n"},{"id":"464865","messageId":"xmqq35briuel.fsf@gitster.g","threadId":"58616","inReplyTo":"221013.86o7uflvcv.gmgdl@evledraar.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-13T16:02:26Z","receivedAt":"2022-10-13T16:02:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> In apply.c's parse_fragment() we seem to only care that we find a\n> \"\\\"-line that's at least the length of \"\\ No newline...\".\n\nIf I recall correctly, this was done very much on purpose back in\n2005 on top of what I and Linus did originally (which was specific\nto \"No newline\" written in C locale).  Because the input from \"git\napply\" may not necessarily be the output from \"git diff\", and in the\nolder days, \"git diff\" spawned platform \"diff\" to show diff, it would\nhave been subject to l10n.\n\nWith GNU diff, I can do\n\n    $ echo -n one >/var/tmp/1; echo -n two >/var/tmp/2\n    $ LC_ALL=ja_JP.utf8 diff -u /var/tmp/[12]\n    --- /var/tmp/1  2022-10-13 08:40:55.393209930 -0700\n    +++ /var/tmp/2  2022-10-13 08:40:59.269538397 -0700\n    @@ -1 +1 @@\n    -one\n    \\ ファイル末尾に改行がありません\n    +two\n    \\ ファイル末尾に改行がありません\n\nAs it does not consider a file that ends with an incomplete line a\ntext file [*], I do not think POSIX says anything about lines that\nbegin with \"\\\" in the \"diff\" output, but I would be surprised if GNU\npatch (or anybody else's, for that matter) did not ignore text on\nthe line, because all of them must be able to parse the above\noutput.\n\n> I wonder what (if any) compatibility issues we'd have if we emitted\n> e.g.:\n>\n> \t\\ The filename pointed to by the symlink does not end in a newline\n\nWhile I do not think it would break anybody, I doubt it would give\nus much value.  One line above that output is a line that any user,\nwho is vaguely familiar with the contents being compared, can\nrecognize as giving a pathname, the contents of the symbolic link.\n\n\n[References]\n\nhttps://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_83\n"},{"id":"464870","messageId":"221013.86k053lkvu.gmgdl@evledraar.gmail.com","threadId":"58616","inReplyTo":"xmqq35briuel.fsf@gitster.g","subject":"Re: About git reporting missing newline for symlinks","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-10-13T16:57:44Z","receivedAt":"2022-10-13T16:59:58Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 13 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> In apply.c's parse_fragment() we seem to only care that we find a\n>> \"\\\"-line that's at least the length of \"\\ No newline...\".\n>\n> If I recall correctly, this was done very much on purpose back in\n> 2005 on top of what I and Linus did originally (which was specific\n> to \"No newline\" written in C locale).  Because the input from \"git\n> apply\" may not necessarily be the output from \"git diff\", and in the\n> older days, \"git diff\" spawned platform \"diff\" to show diff, it would\n> have been subject to l10n.\n>\n> With GNU diff, I can do\n>\n>     $ echo -n one >/var/tmp/1; echo -n two >/var/tmp/2\n>     $ LC_ALL=ja_JP.utf8 diff -u /var/tmp/[12]\n>     --- /var/tmp/1  2022-10-13 08:40:55.393209930 -0700\n>     +++ /var/tmp/2  2022-10-13 08:40:59.269538397 -0700\n>     @@ -1 +1 @@\n>     -one\n>     \\ ファイル末尾に改行がありません\n>     +two\n>     \\ ファイル末尾に改行がありません\n>\n> As it does not consider a file that ends with an incomplete line a\n> text file [*], I do not think POSIX says anything about lines that\n> begin with \"\\\" in the \"diff\" output, but I would be surprised if GNU\n> patch (or anybody else's, for that matter) did not ignore text on\n> the line, because all of them must be able to parse the above\n> output.\n\nThat's really informative, thanks.\n\n>> I wonder what (if any) compatibility issues we'd have if we emitted\n>> e.g.:\n>>\n>> \t\\ The filename pointed to by the symlink does not end in a newline\n>\n> While I do not think it would break anybody, I doubt it would give\n> us much value.  One line above that output is a line that any user,\n> who is vaguely familiar with the contents being compared, can\n> recognize as giving a pathname, the contents of the symbolic link.\n\nClearly it confused the initial reporter upthread :) I'm not going to\npursue it, but it seems to me that we're being sloppy here in including\na message that makes more sense for a normal diff when we could consider\nthe mode(s) involved, as it's not abnormal for a filename to be missing\na trailing \"\\n\" (having a \"\\n\" being the odd case).\n\nAnyway, I'm not going to pursue changing the message, but maybe if\nsomeone else is interested the above compatibility notes would be\nvaluable, thanks!\n"},{"id":"464880","messageId":"xmqqtu47fti9.fsf@gitster.g","threadId":"58616","inReplyTo":"221013.86k053lkvu.gmgdl@evledraar.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-13T18:50:06Z","receivedAt":"2022-10-13T18:54:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>>> \t\\ The filename pointed to by the symlink does not end in a newline\n>>\n>> While I do not think it would break anybody, I doubt it would give\n>> us much value.  One line above that output is a line that any user,\n>> who is vaguely familiar with the contents being compared, can\n>> recognize as giving a pathname, the contents of the symbolic link.\n>\n> Clearly it confused the initial reporter upthread :)\n\nBut to such a user, I highly suspect that the rephased message above\nstill looks like a warning, and will result in the same reaction.\n\nIOW, you want to explain why \"does not end in a newline\" is worth\nexpressing in the output.  Saying \"does not end in a newline\" alone\nwould tell the user what they already know (i.e. the symlink stores\nthe target filename without an extra LF at the end).\n\n"},{"id":"464885","messageId":"221013.8635brldj4.gmgdl@evledraar.gmail.com","threadId":"58616","inReplyTo":"xmqqtu47fti9.fsf@gitster.g","subject":"Re: About git reporting missing newline for symlinks","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-10-13T19:33:28Z","receivedAt":"2022-10-13T19:38:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 13 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>>>> \t\\ The filename pointed to by the symlink does not end in a newline\n>>>\n>>> While I do not think it would break anybody, I doubt it would give\n>>> us much value.  One line above that output is a line that any user,\n>>> who is vaguely familiar with the contents being compared, can\n>>> recognize as giving a pathname, the contents of the symbolic link.\n>>\n>> Clearly it confused the initial reporter upthread :)\n>\n> But to such a user, I highly suspect that the rephased message above\n> still looks like a warning, and will result in the same reaction.\n>\n> IOW, you want to explain why \"does not end in a newline\" is worth\n> expressing in the output.  Saying \"does not end in a newline\" alone\n> would tell the user what they already know (i.e. the symlink stores\n> the target filename without an extra LF at the end).\n\nYes, but isn't the point of the report/confusion that we're inserting\nwhat looks like the warning you get when you forget a \\n at the end of a\nsource file, so a user might wonder why they're seeing it at all.\n\nWhereas what we're *really* doing there is not really about that at all,\nbut just inserting a bit of magic so that the diff format & its\nconsumers grok that this line we're inserting there isn't supposed to\nhave a \\n, as we're working with a filename.\n\nMaybe e.g.:\n\t\n\tdiff --git a/RelNotes b/RelNotes\n\tindex d505db645be..758368388a4 120000\n\t--- a/RelNotes\n\t+++ b/RelNotes\n\t@@ -1 +1 @@\n\t-Documentation/RelNotes/2.38.0.txt\n\t\\ No newline at end of file\n\t+Documentation/RelNotes/2.39.0.txt\n\t\\ No newline at end of file\n\nWould, for those users, be less confusing as:\n\n\tdiff --git a/RelNotes b/RelNotes\n\tindex d505db645be..758368388a4 120000\n\t--- a/RelNotes\n\t+++ b/RelNotes\n\t@@ -1 +1 @@\n\t-Documentation/RelNotes/2.38.0.txt\n\t\\ The symlink above has no trailing NL in its filename\n\t+Documentation/RelNotes/2.39.0.txt\n\t\\ The symlink above has no trailing NL in its filename\n\n*dunno* :)\n\t\n"},{"id":"464886","messageId":"xmqqmt9zfpz7.fsf@gitster.g","threadId":"58616","inReplyTo":"221013.8635brldj4.gmgdl@evledraar.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-13T20:06:20Z","receivedAt":"2022-10-13T20:06:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> Would, for those users, be less confusing as:\n>\n> \tdiff --git a/RelNotes b/RelNotes\n> \tindex d505db645be..758368388a4 120000\n> \t--- a/RelNotes\n> \t+++ b/RelNotes\n> \t@@ -1 +1 @@\n> \t-Documentation/RelNotes/2.38.0.txt\n> \t\\ The symlink above has no trailing NL in its filename\n> \t+Documentation/RelNotes/2.39.0.txt\n> \t\\ The symlink above has no trailing NL in its filename\n>\n> *dunno* :)\n\nI do not think so, but \"The symlink lacks the terminating LF and it\nis perfectly normal\" would be an OK thing to say.  It would make it\nclear that it is not a warning message.\n"},{"id":"464889","messageId":"aead3926-d87b-5fcd-4984-bb690f3fbf4e@iee.email","threadId":"58616","inReplyTo":"221013.8635brldj4.gmgdl@evledraar.gmail.com","subject":"Re: About git reporting missing newline for symlinks","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-10-13T20:34:41Z","receivedAt":"2022-10-13T20:34:58Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"\nOn 13/10/2022 20:33, Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Oct 13 2022, Junio C Hamano wrote:\n>\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>\n>>>>> \t\\ The filename pointed to by the symlink does not end in a newline\n>>>> While I do not think it would break anybody, I doubt it would give\n>>>> us much value.  One line above that output is a line that any user,\n>>>> who is vaguely familiar with the contents being compared, can\n>>>> recognize as giving a pathname, the contents of the symbolic link.\n>>> Clearly it confused the initial reporter upthread :)\n>> But to such a user, I highly suspect that the rephased message above\n>> still looks like a warning, and will result in the same reaction.\n>>\n>> IOW, you want to explain why \"does not end in a newline\" is worth\n>> expressing in the output.  Saying \"does not end in a newline\" alone\n>> would tell the user what they already know (i.e. the symlink stores\n>> the target filename without an extra LF at the end).\n> Yes, but isn't the point of the report/confusion that we're inserting\n> what looks like the warning you get when you forget a \\n at the end of a\n> source file, so a user might wonder why they're seeing it at all.\n>\n> Whereas what we're *really* doing there is not really about that at all,\n> but just inserting a bit of magic so that the diff format & its\n> consumers grok that this line we're inserting there isn't supposed to\n> have a \\n, as we're working with a filename.\n>\n> Maybe e.g.:\n> \t\n> \tdiff --git a/RelNotes b/RelNotes\n> \tindex d505db645be..758368388a4 120000\n> \t--- a/RelNotes\n> \t+++ b/RelNotes\n> \t@@ -1 +1 @@\n> \t-Documentation/RelNotes/2.38.0.txt\n> \t\\ No newline at end of file\n> \t+Documentation/RelNotes/2.39.0.txt\n> \t\\ No newline at end of file\n>\n> Would, for those users, be less confusing as:\n>\n> \tdiff --git a/RelNotes b/RelNotes\n> \tindex d505db645be..758368388a4 120000\n> \t--- a/RelNotes\n> \t+++ b/RelNotes\n> \t@@ -1 +1 @@\n> \t-Documentation/RelNotes/2.38.0.txt\n> \t\\ The symlink above has no trailing NL in its filename\n> \t+Documentation/RelNotes/2.39.0.txt\n> \t\\ The symlink above has no trailing NL in its filename\n>\n> *dunno* :)\n> \t\nPondering on why it is thought of as a warning to be treated as an\nerror, maybe the message implies something is missing via the negative\n\"No\" assertion, rather than simply being informative [1].\n\nPerhaps swapping out the \"No\" and instead using something like \"\\\nWithout a newline at end of file\" would better convey that it's just\ninformation about the file's format, and in no way a real problem. Just\na thought.\n--\nPhilip\n[1] My comment in Git Users discussion:\nhttps://groups.google.com/d/msgid/git-users/c4f53bb2-cff6-4a76-8fa7-cd34ca88ce63n%40googlegroups.com\n<https://groups.google.com/d/msgid/git-users/c4f53bb2-cff6-4a76-8fa7-cd34ca88ce63n%40googlegroups.com?utm_medium=email&utm_source=footer>\n\n"},{"id":"464900","messageId":"CA+JQ7M_HJf_o=u4DOjdGet5D88kWEDJ+AbwfAWVnx487VSVu=Q@mail.gmail.com","threadId":"58616","inReplyTo":"aead3926-d87b-5fcd-4984-bb690f3fbf4e@iee.email","subject":"Re: About git reporting missing newline for symlinks","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2022-10-13T22:01:02Z","receivedAt":"2022-10-13T22:01:44Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"On Thu, Oct 13, 2022 at 10:55 PM Philip Oakley <philipoakley@iee.email> wrote:\n>\n> Pondering on why it is thought of as a warning to be treated as an\n> error, maybe the message implies something is missing via the negative\n> \"No\" assertion, rather than simply being informative [1].\n\nVery likely. I imagine most users use diff to view the\nchanges they made without knowledge of the use of diffs in git-apply.\nWithout that background it's more likely to be interpreted as an\nopinionated comment as opposed to being informative.\n\n> Perhaps swapping out the \"No\" and instead using something like \"\\\n> Without a newline at end of file\" would better convey that it's just\n> information about the file's format, and in no way a real problem. Just\n> a thought.\n\nThat's probably less likely to be read as a warning\n"}]}