Reuben Thomas wrote: > 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!
Could some tool you use have converted 8 leading spaces to a TAB in that Makefile? I think emacs' whitespace mode can be configured to do that.
