[Dnsmasq-discuss] [patch] empty empty lines

[john doe]

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.



As an aside:
It looks like tag are not gpg signed

--
John Doe