Re: make change-history on non-master branches

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> 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