Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Mon, 18 Jun 2007, David Kastrup wrote: > >> Jakub Narebski <jnareb@xxxxxxxxx> writes: >> >> > David Kastrup wrote: >> > >> >> what is the point in quoting file names and their characters in >> >> git-diff's output? >> > >> > 7-bit email. >> >> I think it can be reasonably safely assumed that people using 8-bit >> characters in file names will not refrain from using them in the files >> themselves: [...] > > However, please realise that chances are very good that none of these > 8-bit unclean things show in the diff. Puh-leaze. So you prefer a behavior which makes it harder to notice problems, on the chance that it may sometimes work by accident? If you want to process diffs, you need an 8-bit clean (and space-preserving) channel, period. This is the task of mail encapsulation, not of the diff utility. > Besides, the proper fix would probably involve making > none-8-bit-clean diffs binary diffs (for FORMAT_EMAIL only, of > course). This is so utterly absurd for people working on non-English documents that I get the expression you are pulling people's legs considering your Email address. >> So I don't see what quoting such characters in file names is >> supposed to buy with regard to diff output in 7-bit email. > > But isn't that obvious? Even if the diffs are not 7-bit clean, which > I consider as an error, quoting the file names is already half what > is required. What is required is a reliable mail channel, and there are a lot of tools for that, from uuencode to various MIME standards and encapsulation methods. The right tool for the right job. Everything else is a mistake because it makes life harder for everyone, not just those using mail, for no good purpose. > Don't just throw away backwards compatibility, only because it does > not fit your wishes. There is no backwards compatibility involved here _at_ _all_. No current tool can process the quoted mess, not even humans (random octal escape sequences are not more readable than characters, or we never would have progressed beyond ASCII). So you are not talking about backward compatibility, but rather gratuitous forward _incompatibility_, and nobody is better off by the latter. There is no point in making life harder for people using non-ASCII characters when there is absolutely no benefit whatsoever involved for those restricting themselves to ASCII characters. -- David Kastrup - 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
