Mark McLoughlin wrote: > On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote: >> Thanks to Jim Meyering we now have a new git repository, I deprecated the >> CVS repository, it's read only, you should still be able to keep it >> around to make patches for a few weeks if needed. >> The new repo is at: >> http://libvirt.org/git/?p=libvirt.git;a=summary > > Cool stuff! > > Any thoughts on what to do about ChangeLog? > > As an example of a sensible plan, GNOME dropped ChangeLog but some > modules still generate a ChangeLog for tarball releases. See here: > > http://live.gnome.org/Git/ChangeLog +1 I stopped maintaining-in-VC the ChangeLog file for GNU coreutils, too. However, a usable ChangeLog file still appears in each release tarball. It's generated at "make dist" time from commit logs via this rule from Makefile.am: gen_start_date = 2008-02-08 .PHONY: gen-ChangeLog gen-ChangeLog: if test -d .git; then \ $(top_srcdir)/build-aux/gitlog-to-changelog \ --since=$(gen_start_date) > $(distdir)/cl-t; \ rm -f $(distdir)/ChangeLog; \ mv $(distdir)/cl-t $(distdir)/ChangeLog; \ fi If you want to continue using a version-controlled ChangeLog file, you'll definitely want to start using this tool from gnulib (just build it and install it in your path, following instructions in the C file): http://git.sv.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c It helps you avoid almost all ChangeLog-related conflicts. The alternative (no vc'd ChangeLog file) is to generate it from commit logs. That's what I do in coreutils, even though conflicts are no longer much of an issue, because I don't like having to keep ChangeLog and commit-log in sync with duplicate info. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list