Sam> How could a newcomer guess why the gcc_force_collect flag needs to Sam> be reset?
Andreas> That is supposed to be written in a comment. The change log Andreas> entry should describe _what_ is being changed, so that you Andreas> can find out when a particular change was made. Out of curiosity, I looked for an example with one of your own commits in the Linux kernel tree and I found one: I think http://tinyurl.com/2j7lt7 is a very helpful explanation of the corresponding change (http://tinyurl.com/2tpw8l). Someone trying to fix a similar bug in another driver will benefit from having this message in the VCS history. A comment in the code would probably have been much shorter than this explanation and would probably not contain the "headphone", "line out" and "muted" words. Once again, I agree that the current mechanism works for GCC developers, but I think it could be much better if: 1- commit messages didn't duplicate ChangeLog entries (maybe by getting rid of ChangeLogs) 2- commit messages contained a synthetic information such as the one provided for peer-review I'm not trying to launch a revolution in the GCC development process, I'm only comparing two ways of documenting changes as they are committed and explaining why I find the Linux way of doing it more useful. As a side note, I know several (sick?) people (including myself) who casually read the Linux kernel RSS feed in their RSS aggregator and find it very insightful (if you exclude the "Merge" messages) while lighter than reading the whole linux-kernel mailing-list. People reading this can look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=atom with RSS-capable software to see what I mean. The GCC ChangeLogs, even when aggregated, aren't as nice to read when you're having breakfast :) Sam
