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.