Hi, On Thu, 12 Oct 2006, Junio C Hamano wrote: > I noticed this breakage sometime last week and it was sitting at near > the bottom of my stack of things to look at. I actually enjoyed tracking your todo "branch", although lately, there is substantially less traffic there. Maybe git is finished ;-) > You mentioned six whitespace problems but I counted only three > and the test failed on "CR at the end"; the test vector was easy > to hand-fix thanks to the "index" line. > > This patch is an example that we do not want to transmit files > that has CRs in e-mail. These CRs appear in format-patch > output, so either the user needs to do --attach (and perhaps the > option needs to do base64 or qp in such a case) or format-patch > needs to treat a blob with CR as binary and emit binary diff? > The latter is not appropriate since patches apply just fine with > CR in them. The problem is more likely my (strange) workflow. I never use git-send-email. Not only because I am a bit wary of the Perl stuff, but also because I cannot use sendmail directly (some stoopid "firewall" pretending to fix spamming from %&/%&/ users with their %&"§ infected Windows machines). Thus, I used ^R in my venerable patched pine to insert the file, and (just a guess) pine -- in its infinite wisdom -- decided I'd probably not want the carriage return, when I put it there on purpose, using my l33t sk1llz. In hindsight, it might be not _that_ important to test for a carriage return, but testing _any_ whitespace should do (which I put in also, for good measure). However, carriage returns from my beloved friends using the Most Stupid operating system were the reason I hacked in the whitespace options, and therefore I wanted to test this case specifically. Ciao, Dscho