Re: make change-history on non-master branches

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <address@hidden>
>> Cc: Andreas Schwab <address@hidden>, address@hidden,
>> address@hidden, address@hidden
>
>> Date: Thu, 19 Nov 2015 20:48:15 +0100
>> 
>> For further ChangeLog updates, at least in the current form, I don't see
>> how to automate this. IMHO, for automatic merges, we would need the
>> following:
>> 
>> - Generating the ChangeLog on the 'master' branch ignores commits from
>>   emacs-25 merges.
>> 
>> - Generating the ChangeLog on the 'emacs-25' branch ignores cherry-picks
>>   from 'master' (can be detected by git or through a magic word in the
>>   commit message).
>> 
>> - when cherry-picking from 'master', we copy the generated&fixed
>>   ChangeLog entry and commit it separately. Then gitmerge.el could skip
>>   that during the merge into master, just like it skips the backported
>>   commit itself.
>
> I'm not sure I understand the practical meaning of the last item
> (which AFAIU is the only one that needs to be done by humans).  You
> seem to say that each cherry-pick should require an update to
> ChangeLog.2 both on master and on emacs-25, and application of fixes
> to them?

Yes.

> Normally, ChangeLog.2 is updated once a week from Git, and then
> whoever has a habit of looking at the results makes corrections there
> when they feel like it.  So there's no guarantee that the corrected
> entry is in place when you cherry-pick.  Moreover, the person who
> cherry-picks does not necessarily know whether the log message of the
> cherry-picked commit needs fixing, or how to fix it.

I'm aware of these problems. But if you simply cherry-pick and let 'make
change-history' do its job on both branches, you will have to fix the
ChangeLog entry twice (preferably the same way), and you'll get a
conflict when you merge emacs-25 into master.

-David