On Mon, 2009-07-06 at 17:22 +0200, Jim Meyering wrote: > Mark McLoughlin wrote: > > On Mon, 2009-07-06 at 16:19 +0200, Daniel Veillard wrote: > >> 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. > > > > Cool. > > > >> On the other hand we > >> should try to keep the git log output coherent with the previous > >> format. > > > > FWIW, I think it's best to switch to a new format that better suits git. > > > > e.g. "git log --pretty=oneline" can be very useful, but only where > > people properly summarise the commit on the first line. If we used the > > typical ChangeLog format, it would be useless. Also, we don't need the > > date and author information twice. > > > > II think git commit messages generally more genuinely useful information > > than a ChangeLog entry - it seems to encourage people to more fully > > explain what they're doing. > > > > If we switch formats, 'git log --stat' is fine for Changelog - you get > > author, date, files changed etc. > > Hi Mark, > > What do you think of coreutils' logs? > It's generated and still ChangeLog-conforming, yet with an added > one-line summary and sometimes (for larger changes) more prose: > > http://meyering.net/code/tmp/coreutils-ChangeLog Looking at the git commits e.g. http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=24c727d3 it doesn't duplicate date/author and has a good first line summary, so it's pretty good. The one question I'd have is whether listing of per-file changes has any value. IMHO, it tends to restrict the explanation people give about about their commits. Looking at projects that don't do this, I think you tend to get much more background on why the change is being made, not just what changed. Cheers, Mark. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list