Re: Merges from release branch (was: Gitlab Migration)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "Philip K." <philipk@posteo.net>,  Daniel
>  Fleischer <danflscr@gmail.com>,  Theodor Thornhill <theo@thornhill.no>,
>   emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  Dmitry Gutov <dgutov@yandex.ru>,  Lars
>  Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Aug 2021 10:53:53 +0100
> 
> 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.