Hi, [sorry for responding so late, your mail got stuck in the GWB-like spam filter.] On Tue, 19 Jun 2007, David Kastrup wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Hi, > > > > On Tue, 19 Jun 2007, David Kastrup wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> > >> > Don't just throw away backwards compatibility, only because it does > >> > not fit your wishes. > >> > >> There is no backwards compatibility involved here _at_ _all_. > > > > I was not talking about Git here. The specification for SMTP is not > > going to change just because you want it. There are still mail > > servers out there which speak 7-bit, and the standard requires you > > to cope with them. > > Is there a reason you elide all the relevant material before replying? > I repeat: this is the task of MIME, uuencode or a number of other > mechanisms. The problem there, of course, is that you still might want to reply to the patch, even if the name was chosen as non-ASCII (which is a sin, if you believe in UNIX). Usually, comments are not done on the filenames, so they can be as escaped as they want in an email, as long as the commenter still recognizes their names. > git is not a mail transport system, and there are far too many other > problems in unarmored mail (like spaces, wrapping and other stuff) that > it would make any sense to mangle diffs and other material in a manner > that makes it quite unprocessable for _both_ human readers as well as > scripts intended to process them. There you have a point. If the name is non-ASCII, it uses a specific encoding. if the human reader has a different encoding set in her display, is it any better to display garbled characters (possibly leaving the console in a corrupted state), or to display escaped characters? And scripts have been known to get encodings all wrong, so I think the escaping is the best way out, absent a perfect knowledge of what encoding the file name was meant for. > Anyway, it has become quite clear from this exchange that you have > already made the decision not to be convinced by me and will not be > deterred from that, even though the problem is not the one you initially > tried deriding me for (spaces in filenames). I am sorry. No, really, I am sorry that you received it as derision. By all means, it was _not_ meant as that. The problem was on my side, not yours: I simply did not get that you were talking about non-ASCII characters, even if you were talking about them. > Hopefully some developer with less of an attitude towards non-ASCII > usage will find himself able to follow the arguments with some more > objectivity. > > I don't see our discourse leading anywhere: the points have been made. I would really, really, really like to see a solution. Alas, I cannot think of one, other than _forcing_ the developers to use ASCII-only filenames. Note that there is no convention yet in Git to state which encoding your filenames are supposed to use. And in fact, we already had a fine example in git.git why this is particularly difficult. MacOSX is too clever to be true, in that it gladly takes filenames in one encoding, but reads those filenames out in _another_ encoding. Thus, a "git add <filename>" can well end up in git-status saying that a file was deleted, and another file (actually the same, but in a different encoding) is untracked. Again, I would be _so_ glad if you solved the problem, now that I actually understand it. Ciao, Dscho - 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
