[OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available
openwrt at daniel.thecshore.com
Sun Jan 10 05:32:34 EST 2016
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.
On 10/01/16 05:20 AM, Daniel Dickinson wrote:
> On 10/01/16 05:10 AM, Gert Doering wrote:
>> 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
> 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
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel