Re: Merges from release branch

[David Engster]

>> This is a tangent, but we also have some practice here in Emacs which I
>> don't fully understand, which is to "merge back from release branches"
>> to integrate fixes from those branches into 'main'.  That in itself
>> already opens the doors to "duplicated commits" if special care isn't
>> taken.  That's because these merges are special: they somehow don't
>> contain all of the stuff that was present in the release branches.  See,
>> for example, this commit:
>> 
>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>     Merge: 979f14e641 5b03849102
>>     Author: Glenn Morris <rgm@gnu.org>
>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>      
>>         ; Merge from origin/emacs-27
>>      
>>         The following commit was skipped:
>>      
>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests 
>> ...
>
> What problems do you see with these merges?  I don't think I follow.
>
> The commits are skipped either because they are marked "not to merge"
> (meaning they are inappropriate for master) or because master already
> has the same or a different fix.

I think João is confused how you would "skip" a commit in a merge,
because you actually can't. The more proper way would be to say "this
commit was separately merged with the strategy 'ours'", but this is
quite a mouthful. The merge stategy 'ours' simply means that the content
of the merged commits is discarded, but it's a perfectly valid way to
merge, so nothing "evil" about it.

-David