Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > I'm sorry, but that makes 3 out of 3 respondents who didn't seem to read > what I wrote. You seem to think three out of three people didn't read nor understood your argument, but my take on it is that three out of three of people who cared about the issue thought your justification was not convincing. Symlinks are minority among the tracked contents (e.g. in git.git there is only one), and they are almost always a single incomplete line. When they change, you do want to notice, and I happen to find it a good visual aid to have these incomplete line indicators, in addition to the unusual 120000 mode on the index line. Peff uses --textconv to show changes to the exif information on his photo collections. If he has any symlinks, and if he finds that removal of "\No newline" is a regression and not an improvement, what recourse does your patch give him? Saying --no-textconv to work around that regression is not a solution, isn't it? If you start from a false premise that "\No newline" was an unnecessary warning, it may seem that the output (which almost always is given for symlinks) needs "improving". But have you considered a possibility that removal of the line from the output is not an improvement? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html