Re: make change-history on non-master branches

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Glenn Morris <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Wed, 18 Nov 2015 13:28:08 -0500
>> 
>> Eli Zaretskii wrote:
>> 
>> > Right.  But if we merge ChangeLog.2 from the release branch to master,
>> > then this will produce a mess when "make change-history" is run on
>> > master, no?  I mean, some entries will appear twice, once after
>> > corrections, the other without.  No?
>> 
>> Quite possibly. I don't know exactly what happens if the commit hash
>> from the ChangeLog.2 footer were to get merged between branches.
>> 
>> I don't know how to solve this problem, but it seems to me that it needs
>> to be solved, and the more master and emacs-25 diverge, the worse it
>> gets.
>
> I agree.
>
> Perhaps Git gurus could help us out?  Andreas, any suggestions?

man git-log

        --cherry-pick
            Omit any commit that introduces the same change as
            another commit on the "other side" when the set of
            commits are limited with symmetric difference.

            For example, if you have two branches, A and B, a usual
            way to list all commits on only one side of them is with
            --left-right (see the example below in the description
            of the --left-right option). However, it shows the
            commits that were cherry-picked from the other branch
            (for example, "3rd on b" may be cherry-picked from
            branch A). With this option, such pairs of commits are
            excluded from the output.

[...]

        --cherry
            A synonym for --right-only --cherry-mark --no-merges;
            useful to limit the output to the commits on our side
            and mark those that have been applied to the other side
            of a forked history with git log --cherry
            upstream...mybranch, similar to git cherry upstream
            mybranch.


-- 
David Kastrup