[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make change-history on non-master branches

From: Eli Zaretskii
Subject: Re: make change-history on non-master branches
Date: Thu, 19 Nov 2015 22:38:32 +0200

> 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?  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.

Or maybe I misunderstood the proposal.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]