Re: ChangeLog rotation (or... eliminating ChangeLogs)

[Alan Modra <amodra at gmail dot com>]

On Wed, Jan 11, 2017 at 11:07:57AM -0500, Paul Smith wrote:
> On Wed, 2017-01-11 at 18:53 +1030, Alan Modra wrote:
> > On Tue, Jan 10, 2017 at 12:11:11PM -0800, Cary Coutant wrote:
> > > What's the rationale for rotating ChangeLogs every year? To me, it's
> > > much simpler to have a single monolithic file -- especially
> > > considering that wildcard substitution puts the files in ascending
> > > order, while searching within a file returns results in descending
> > > order.
> > 
> > We haven't been using git for all that long.  With CVS, I believe that
> > any changed file is transmitted to the repository in entirety when
> > committing (and also for other operations).  Large frequently changed
> > files therefore created a network traffic problem on the server.
> > Locally too if you were on 300 baud dialup.  :)
> 
> In Git only diffs are transmitted so that part is not a big problem.

Yup.

> However, it is frustrating to deal with ChangeLogs because all changes
> always come at the front of the file which means every change is always
> a conflict that needs to be resolved.

Yes, until you discover git-merge-changelog.c (another nice utility
found in gnulib).

> Other GNU tools have changed to use the gitlog-to-changelog utility from
> gnulib, then they don't keep changelogs at all as files in the repo:
> instead they're generated from the Git log when the package is created.

I'd be happy for binutils to use this.  As a maintainer, I hardly ever
use ChangeLog files any more to investigate history.
"git log interesting_file",
"git blame interesting_file" and
"git blame commit_id^ interesting_file" are my preferred methods.

-- 
Alan Modra
Australia Development Lab, IBM