Petr Stehlik wrote:
if you are happy with the result then cvs diff -Naur > fix_for_Frank.diff
And I would add another thing (finally, several things).Before submitting a patch, I always write a CVS description, and I check that *every* line modified in the patch serves that purpose. I also check I used the correct coding style (indent size, tabs or spaces, brace position...)
If the patch contains some debug code I added to see what was going on, I remove it. If it contains other changes than the targeted objective, I keep these additional changes somewhere, to make another patch later when it is totally finished.
That way, the purpose of the patch is clearly identified and anyone can proof-read it without being disturbed by noise. The patch can be committed safely by a maintainer, and could be undone if finally it appears to be bad.
Furthermore, by posting the patches to a mailing list instead of a specific developer, it can bee proof-read by anyone, and it is archived in the mailing list archives, so it can be found when seeking some specific information.
Another source of headaches: we must absolutely post patch files with UNIX line endings. Some editors in Windows (like my favorite Visual C++ 6) always add CR+LF on the modified lines on a file, but don't modify the untouched lines. These additional CR then goes into the patch files, and in the sources of the other developers... It does not really matter for C files, but for Makefiles or shell scripts it can lead to ununderstandable errors.
And I take this occasion to say again what Frank said recently: when providing a patch for any project stored in the SpareMiNT CVS repository, we don't have to modify the ChangeLog file. Instead, we just have to provide (in the email) some lines of explanation that will be used as "description" during the CVS commit. These descriptions will be used automatically by a script to generate the ChangeLog file (with the list of modified files) when making an official release.
-- Vincent Rivière