Re: master cbef1e9 2/3: ; make change-history-commit

[Glenn Morris <rgm@gnu.org>]

Paul Eggert wrote:

> ChangeLog.1 would contain top-level entries predating April 7, and
> ChangeLog.2 would contain all entries between April 7 and the most
> recent 'make change-history'.

That sounds better to me. Eg I think it would make life easier for
authors.el.

>> Suppose we improve/change the ChangeLog generation script, and want to
>> regenerate the generated ChangeLog. It will be difficult to extract the
>> various corrections that have been applied by hand to the generated
>> entries.
>
> That shouldn't be a problem, as the newly-generated ChangeLog
> shouldn't include any hand-corrected entries.

I seem to be persistently mis-communicating. Let me try again:
In the repo right now, ChangeLog.1 contains entries generated from
commit logs. It also contains some hand-written corrections to a few
of those entries. Suppose we tweak the generation script, and want to
regenerate _all_ entries from Apr 7. E.g. if bug#20325 gets fixed.
It will be difficult to do that without losing the hand-written corrections.

> No, the automatically-generated 'ChangeLog' entries start from the
> last time 'make change-history' was run.

Right. As I was saying, this is not how I expected it to work.

I expected any corrections would be applied to the commit logs, not the
generated C'log. Doing it the former way means the full C'log from Apr 7
can be regenerated whenever necessary, and also means there is no need
to store entries that do not need to be corrected in the repo.

I suggested using git notes for that, but it could just as well be a
flat text file in admin/ that contains a list of (hash + corrected log
for that hash). The generate script could check for an entry in that
file. If there isn't one, use the commit log as-is.

>> erc uses a non-standard scheme where .YY contains the entries for 20YY.
>
> Ah, sorry, I didn't know that.  We could proceed as you suggest,
> though we'd need to add a line to Makefile.in.  Please see the second
> attached patch (it's so large that I gzipped it).  (I haven't tested
> this either.)

I haven't tested either, but sounds like the right idea to me.