On 26 January 2011 22:03, Jim Meyering <[email protected]> wrote: >>> If you think one is obviously better than the other, >>> please explain why along with a patch to improve things. >> >> I don't have an opinion on which is better, just that they should be >> consistent. > > Try to justify one position or the other, then.
I really don't know, I don't see really understand the grouping of options either way. I was just making a bug report, not trying to suggest how to fix it (I'll concentrate on my patches for now). > Perhaps your editor modified the patch? > I confirmed that it worked for me. > The patch I applied started with this line: > From 331804557bcbe8fc7a96b4bd256b4bfb901930fb Mon Sep 17 00:00:00 2001 > ended with two blank lines after "1.7.3.5.38.gb312b", and had OK, I download the mail, I chop up to that From line, check the file ends as you specify, and save it. Just so I can be sure it's not Emacs doing something funky, I did it in Zile. The result does not have the SHA1 checksum you specify. (It is 0e8e61eaf22422f5d24d0fdc0a7601f0806e1611.) Line endings conversion in my mailer? I don't know. But in any case: > Your patch included a change there that converted 8 spaces to a TAB. That's right, but I'm not applying something to reverse my patch, I'm applying to a clean git checkout, as you specify. So why is this line being patched at all? The line already has 8 spaces at the start in my clean git checkout! OK, since it doesn't matter, I'll just get on with it. -- http://rrt.sc3d.org
