> The patch looks fine. If you want, I can install it. BTW, when applying patches in git on behalf of someone else, it's useful to preserve the authorship of the patch by either using “git commit --author 'Foo Bar <f...@mail>'” when applying them manually, or with “git am” when getting them from a mail box (which additionally removes anything between [] from the Subject and also preserves the author date). This way both the committer and the actual author get recorded, and it makes it way more easier to track and analyze them using git commands, for example with “git log” --author or --committer, “git shortlog” to get a list of contributors, etc. One can always also see both with --format=full with commands like “git show” or “git log” and similar.
We use ChangeLog for tracking who the contributor is (for copyright reasons), tracking who the commiter isn't that useful. Many patches do not follow our standards, so blindly commiting them is out of the question. Also you'll find that if people are asked to provide the ChangeLog entry in the actual patch, you'll usually get conflicts, the other option, having them in the comments to be transferred later on to the actual file, imply having to amend the changes after commit, or use stuff like “git am -i”. This is not that hard to fix before a commit, we had to do it for CVS and it is no different now. When sending patches, the ChangeLog entry should simply not be part of the actual patch. And in many cases we need to fix the ChangeLog entries, since they are incorrectly formated, or are missing information. Take the simple example that you are using one space after end-of-sentence periods, in the GNU project we use two; so I'd need to fix that before commiting. :-) Still, for sanity's sake I'd recommend either autogenerating the ChangeLog at “make dist” time from the git log ouput, and having normal git one line summary (the one coming from the mail Subject), and optionally more paragraphs describing why the patch or more details like error output, etc, and then the normal ChangeLog formatted entries. Or a bit more revolutionary would be to prescind of the ChangeLog file, which IMO is a relic from the RCS/CVS times, tools which were unable to properly record authorship, do aotmic commits, and be able to analyze and check in a fast way all previous history. Which seem to be the main reasons exposed in the GCS for a ChangeLog. This will simply not happen, one cannot modify a commit log after the fact, which would produce incorrect ChangeLog entries. Thank you for your suggestion though, they are most welcome even if we might not implement them. PS. RCS did do atomic commits.
