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:
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.