Re: On autogenerated ChangeLog

[Jonathon Jongsma <jonathon quotidian org>]

Alexander Larsson wrote:
> On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
> > On 04/20/2009 09:02 AM, Bastien Nocera wrote:
> > > On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote:
> > > > On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote:
> > > > > Hey,
> > > > >
> > > > > I first wrote Makefile.am magic for Pango to generate ChangeLog from git on
> > > > > demand.  Those macros have been modified and gathered in
> > > > > http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for "make
> > > > > dist".  I wonder what people actually want to have, so I can work on canonical
> > > > > macros to copy across projects (and eventually find a better way to
> > > > > distribute).  Pros and cons:
> > > > I tweaked this macro a bit for gvfs and nautilus:
> > > >
> > > > Here is what I use:
> > > > git log --stat -M -C --name-status --date=short --no-color | fmt --split-only
> > > >
> > > > Its uses less space and is imho just as useful for causual offline use.
> > > > And if you want more there is git anyway.
> > I like the more verbose format clearly showing which changes are big and which 
> > are small.
>
> Well, I don't really disagree that its nice to know. However, all such
> info is readily availible in git, and can be posted in e.g. a release
> mail for all the recent changes. However, the autogenerated ChangeLog
> file will contain *all* post-git conversion changes, and especially with
> micro-commits this will be a lot, so it will eventually be quite large.
> So, it would be nice to do whatever we can to make our tarballs smaller
> that doesn't have a major impact on the usability, and while there is
> some loss of "functionallity" its not large, and we don't lose anything
> compared to the old ChangeLog entries. 
>
> Same thing with the dates. The old ChangeLog only had dates, not time,
> so there is imho no loss in just using dates in the autogenerated file.

I agree with alex.  The changelog should be easily readable.  big strings of +++++++------ 
make it harder to scan.  If we want that detailed level of information, we can always 
extract it from git on demand anyway.

--
jonner