Syslinux - Oct 2015 - com32/mboot/map.c: removed trailing spaces

On Sat, Oct 10, 2015 at 03:10:26PM +0300, Ady via Syslinux
wrote:
> From: Geert Stappers <stappers at nero.gpm.stappers.nl>
> > 
> > com32/mboot/map.c: removed trailing spaces
> > 
> > They were introduced by the patch for ELF64 support.
> 
> 
> IMHO, the trivial trailing-space cleanup could be included in the same 
> commit too, instead of adding an additional commit just for it. That 
> is, if there is no additional correction / improvement required.
I think it is a good thing to just accept a patch that is good enough
and do reflow work in an additional patch.

I see several advantages:

 * a clear signal of "patch accepted"
 * making visible how a patch is made better
 * no merge conflict for those who have the original patch applied


Groeten
Geert Stappers
-- 
Leven en laten leven

On Tue, Oct 13, 2015 at 5:17 PM, Geert Stappers via Syslinux
<syslinux at zytor.com> wrote:
> On Sat, Oct 10, 2015 at 03:10:26PM +0300, Ady via Syslinux wrote:
>> From: Geert Stappers <stappers at nero.gpm.stappers.nl>
>> >
>> > com32/mboot/map.c: removed trailing spaces
>> >
>> > They were introduced by the patch for ELF64 support.
>>
>>
>> IMHO, the trivial trailing-space cleanup could be included in the same
>> commit too, instead of adding an additional commit just for it. That
>> is, if there is no additional correction / improvement required.
>
> I think it is a good thing to just accept a patch that is good enough
> and do reflow work in an additional patch.
>
> I see several advantages:
>
>  * a clear signal of "patch accepted"
>  * making visible how a patch is made better
>  * no merge conflict for those who have the original patch applied
>
>
> Groeten
> Geert Stappers
> --
> Leven en laten leven
I see advantages both ways.  For so few lines, it can be debatable.
For many lines or if the patch was already in a git repo that could be
merged, it can be better to separate.

Looking around, there appear to be a lot of small places needing some
whitespace cleanup/reconciliation.

I already merged it as an edited merge with addendum to note such.

-- 
-Gene

> Looking around, there appear to be a lot of small places needing some
> whitespace cleanup/reconciliation.
> 
 
Just to be clear, I am not criticizing, but actually asking...

Are those white-space characters impacting the binaries being built?

Would they affect common users?

Are those characters affecting developers? For instance, do they affect 
some git command? Or, do they make the code more difficult to read / 
follow / analyze / debug / patch?

If a commit correcting these white-space characters were to be merged, 
would you consider also merging commits correcting typos that do not 
affect the code itself (e.g. "auxilliary" to "auxiliary";
"AFP" to
"APM" in isohybrid-related code...)? Perhaps all these corrections 
could be made in one "correct typos" commit?
 
> I already merged it as an edited merge with addendum to note such.
Thank you.
 
> 
> -- 
> -Gene
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

2015-10-14 1:45 UTC+02:00, Gene Cumm via Syslinux <syslinux at
zytor.com>:
> On Tue, Oct 13, 2015 at 5:17 PM, Geert Stappers via Syslinux
> <syslinux at zytor.com> wrote:
>> On Sat, Oct 10, 2015 at 03:10:26PM +0300, Ady via Syslinux wrote:
>>> From: Geert Stappers <stappers at nero.gpm.stappers.nl>
>>> >
>>> > com32/mboot/map.c: removed trailing spaces
>>> >
>>> > They were introduced by the patch for ELF64 support.
>>>
>>>
>>> IMHO, the trivial trailing-space cleanup could be included in the
same
>>> commit too, instead of adding an additional commit just for it.
That
>>> is, if there is no additional correction / improvement required.
>>
>> I think it is a good thing to just accept a patch that is good enough
>> and do reflow work in an additional patch.
>>
>> I see several advantages:
>>
>>  * a clear signal of "patch accepted"
>>  * making visible how a patch is made better
>>  * no merge conflict for those who have the original patch applied
>>
>>
>> Groeten
>> Geert Stappers
>> --
>> Leven en laten leven
>
> I see advantages both ways.  For so few lines, it can be debatable.
> For many lines or if the patch was already in a git repo that could be
> merged, it can be better to separate.
>
> Looking around, there appear to be a lot of small places needing some
> whitespace cleanup/reconciliation.
>
> I already merged it as an edited merge with addendum to note such.
>
> --
> -Gene
Some reading from Greg KH (a Linux developer) about first patches and
whitespaces commits.
https://lwn.net/Articles/658231/

That might be of interest for some of you.


Celelibi