[OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available

[Daniel Dickinson]

And yes you could make a regex that detect any sets of 8 spaces before 
non-whitespace text, but that seems like a lot of effort for no good 
reason, when not dealing with Makefiles.

Anything that applies a *hard* rule about whitespace is broken - 
whitespace shouldn't be getting converted unless it's actually 
necessary; a hard rule will fail under some conditions, and the real 
issue is editors *changing* whitespace without user interaction (which 
causes patches to fail).

Indead git's insistence on the exact same whitespace is the root issue, 
since changing git would be a lot easier than changing a bazillion 
editor to suite git (hint: ain't gonna happen).

I'm sure this has been discussed to death, but having patchwork be a 
knob isn't the answer.

Regards,

Daniel

On 10/01/16 05:20 AM, Daniel Dickinson wrote:
> Hi,
>
> On 10/01/16 05:10 AM, Gert Doering wrote:
>> Hi,
>>
>> On Sun, Jan 10, 2016 at 04:47:05AM -0500, Daniel Dickinson wrote:
>>> I used git send-email so there shouldn't be any whitepspace mangling
>>> issues, unless patchwork is to blame.
>>
>> Over at openvpn-devel, we recently discovered that some versions of
>> MS Exchange mangle whitespace for "mails in transit" - so even when the
>> user did everything right (git send-email, etc.) Exchange still converted
>> all tabs to 8x Space, leading to non-applying patches.
>>
>
> I think this is a different issue. The issue here is that there is
> indeed 8 spaces instead of a tab, *however* it's in a shell script AND
> git doesn't complain, nor do regexes that detect things like spaces
> before tabs (there is no tab after the spaces, only non-whitespace
> text). In short patchwork appears to say 'for *all* files, you *must*
> use tab instead of 8 spaces', which is not reasonable, and in some cases
> is actually wrong.
>
> Also I am pretty certain provider is not running Windows, nor is
> OpenWrt, so that is not likely to at issue.
>
>> Solution: send via freemail provider, using direct SMTP+Auth (which
>> git send-email can do).
>>
>>> That leaves receive-side error.  It seems likely given the line the
>>> error is on, that patchwork is pickier than git or the vim bit you sent
>>> me.  That is the 'offending' line is a shell script that happens to have
>>> 8 spaces instead of tab.  Methinks this is not a relevant thing to
>>> complain about in a shell script; also I wonder whether it would do the
>>> same with with e.g. Python?  I suspect patchwork is applying Makefile
>>> rules to all patches, which is just wrong.
>>
>> The problem often is context.  If the parts before or after the actual
>> change get whitespace-modified, git am will not accept it (traditional
>> patch will, and complain about fuzz needed).
>
> However, the error being reported is not 'patch does not apply', it is
> 'whitespace error', which implies that it's something patchwork is
> reporting.
>
> Perhaps the error report really should be 'patch does not apply because
> of whitespace error', but that is not what I was told, so I'm left
> guessing.
>
> Regards,
>
> Daniel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel