On Sat, 28 Jan 2012, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> Ondra Medek <xmedeko@xxxxxxxxx> writes: >> >>> we have gitweb running on Linux box. Some files have Windows line ending >>> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r >>> in the end of each line, which is annoying. >> >> Well, this "\r" allows to recognize when file with Windows line ending >> (CRLF) made it into repository... which usually is discouraged. But >> if you allow this, I can understand that those "\r" at the end of >> every line can be annoying. > > I think the right thing to do is: > > * If the repository data is _supposed_ to have CRLF endings (e.g. check > with core.crlf or something), strip \r and do not show them. > > * Otherwise, i.e. if the repository data is supposed _not_ to have CRLF > endings, do show these '\r'. Annoyance here is a *feature* to remind > the viewer that the contents needs _fixing_. > > * No other switches. I agree that it would be a bast solution if gitweb could automatically infer whether CRLF is allowed (whitelist) or disallowed (blacklist) in files in given repository. But I am not sure if it is possible and what rules there should be for a *BARE* repository; crlf and eol gitattributes and config variables are about what should appear in working area - something gitweb is not interested in at all. If gitweb code was structured in different way, we could check if all lines end in LF or all lines end in CRLF and add a note about that to file or diff header, showing "\r" only in case of mixed line endings... But that's a futile wish, for now at least. -- Jakub Narebski Poland -- 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