> This *is* the information I would expect to be present somewhere in > GCC history. A clear and detailed information on why the change was > necessary. Sure, in some case the checkin references a PR, but the PR > often contains information of what didn't work before the change and > the same information which is already repeated three times (ChangeLog, > svn log and svn diff).
Keep in mind that the GNU coding standard introduced ChangeLogs before networked version control systems. In those days, you would receive a GCC release tarball with a ChangeLog. There was no way to do "svn log" or "svn diff" operations. Even in recent years, I have worked on GCC trees that were exported from the version control systems of other companies and that I did not have access to. In these situations, ChangeLogs are quite a bit more valuable. Having said that, I find the lack of rationale for some changes to be a bit irritating. I know that this should be done through code comments, but those are often made across the changeset and in different files. There is rarely a single summary of the need for the change. It would be nice to consider a practice similar to that used by NetBSD, which is to use a paragraph or so describing the need for the change (similar to what we do when we introduce a patch on gcc-patches) and inserting that comment into the svn commit message. Ben
