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.
yeah, I think moving ChangeLog to ChangeLog.CVS and generating the
logs starting from today at "make dist" time is probably the best, it
will avoid copying over redundant informations. On the other hand we
should try to keep the git log output coherent with the previous format.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit