On 21 March 2012 21:02, Peter Portante <peter.porta...@redhat.com> wrote: > Please forgive me if you find these changes are annoying, as I am trying to > learn the ropes of patch submission with git ahead of making a real patch.
I'd recommend using git format-patch's --cover-letter option to create your 'cover letter' patch, as this will include a diffstat and summary of all the patches in the patchset. > While working on the code, I found that scripts/checkpatch.pl will flag lines > that I am changing as not adhereing to the codeing standard due to > pre-existing coding violations. So I figured I could learn a bit about how to > submit patches by fixing these files I will be touching before submitting the > code changes. Whitespace-fixes and other coding-style-only changes are a bit of a touchy issue here; they've caused long mailing list arguments in the past. Mostly the line we seem to take is "fix issues in new code submitted; when patching old code you can fix problems complained about in the immediately surrounding few lines". The idea is that gradually the codebase moves into line with the style guide without having massive style-only changes that break tools like 'git blame'. Small changes (like the qemu-timers one) are more likely to be accepted than massive ones (like the slirp patches). Also, it would be helpful if you could split your patches more logically into smaller ones which touch the different subsystems: any patch which touches all of block_int.h, qemu-timer.c and slirp is going to struggle to be reviewed and committed because it is trying to modify three different bits of the codebase and so it needs agreement from more people. Sometimes a patch really does have to touch several different areas, but in this case you're only putting roadblocks in your own path... -- PMM