In-Reply-To: <>
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.

Machine readable version is

Tooling they use is `clangformat`

Please take the above information as input for moving Dnsmasq from
a project without a coding style to a project with a coding style.

Geert Stappers
Leven en laten leven

Dnsmasq-discuss mailing list

Reply via email to