On Sat, Jul 5, 2008 at 11:24 AM, Edward Z. Yang <edwardzyang@xxxxxxxxxxxxxxxxx> wrote: > As a policy on a project that I manage, almost every commit warrants a > change to our NEWS (changelog) file, which end-users can browse to get > an in-depth idea of the changes that have happened from the last > release. If it's an added feature, the changelog includes a description > of how to use it; if it's a fixed bug, it briefly describes what > happened. Internal changes may or may not get added, depending on the > visibility of the APIs affected. I believe it is better to put all this information directly to the commit message using some special tagging, so you can extract it automatically at the release time and generate the changelog file for users. You may edit the generated changelog and commit it directly before release. Having one file changed on almost every commit is not a good idea, and not only because it will cause unnecessary conflicts but also it may considerable increase the size of the whole repository. By default, the delta compression has limit 50, which means that every 50 change of file will become its full copy. If the changelog file is changed very often and it is long, it may turn out that changelog alone takes as much space as the rest of the source tree. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
