On 10/10/2019 22:00, Geert Stappers wrote:
> In-Reply-To: <55adb604-91a9-77a8-ed41-500363f4c...@mail.com>
> Previous-Subject: Re: [Dnsmasq-discuss] [patch] empty empty lines
> On Mon, Sep 30, 2019 at 07:18:12PM +0200, john doe wrote:
>> On 9/30/2019 4:50 PM, Simon Kelley wrote:
>>> To be clear, I have no objection to this sort of patch/suggestion.
>>> It should be fairly clear, however, that my available time to work on
>>> dnsmasq at the moment is limited, and stuff like this is not a priority,
>>> and likely to be pushed to the back of the queue, possibly so far that
>>> it never emerges again.
>>> If we're going to do this, the first stage is probably to add hooks to
>>> git to run expand (for tabs) and this filter on all NEW commits. Then
>>> we won't ever have to do that again.
>>> As that filter will make massive  updates to existing code, we'll have
>>> to take a one-time commit across the codebase to get everything fixed
>>> once. Otherwise the filters will adding lots of extra formatting changes
>>> to other commits as they touch files, which is not good.
>>> So, let's come to a consensus if a one-time clean up commit across the
>>> codebase is a price worth paying to fix the formatting issues, and if it
>>> is, work out how to add automatic filters to git to keep things clean
>>> afterwards. If anyone has experience of that, I'd like to hear.
>> The way I see things which is up for debate:
>> - Everyone that is committing to the project would need to use a Git
>> hook that would avoid committing if the code is not conform to the
>> standard used by the project
>>     The pre-commit hook '.git/hooks/pre-commit' would need to be
>> modified to fit the coding stile required by the project which means
>>  that patch that does not comply to  the coding stile will be rejected.
>> The above is only for new code that would be added, now to the question
>> of modifying code already pushed:
>> If we choose to reformat old pushed code, one commit should be created
>> including all the formatting issues then testing will need to be done to
>> verify that the commit in question does not introduce regression,
>> reformatting old code is questionable to say the lease.
> Where it is OK to get tooling to bend our source code in shape,
> is it more important to decide in which shape it should be bend.
> Here I think it is wise to be standing on the shoulders of giants.
> The giants are this time the Linux Kernel developers.
> Those giants have their coding style described.
>  https://www.kernel.org/doc/html/v5.3/process/coding-style.html
> Machine readable version is
> at 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/.clang-format
> Tooling they use is `clangformat`
>  https://clang.llvm.org/docs/ClangFormat.html
> Please take the above information as input for moving Dnsmasq from
> a project without a coding style to a project with a coding style.

This seems to have escalated from inconsistent use of spaces and tabs to
"without a coding style". For information, the C coding style in dnsmasq
is the GNU style, except without the space preceding (

I like that style, I chose that style and it's not going to change.


Dnsmasq-discuss mailing list

Reply via email to