Re: Merges from release branch

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

I think I understand fully the reasons _why_ they are skipped.

Here's the source of my comment/confusion: normally, in a merge, I have
the expectation that the ancestors of the each branch being merged
become ancestors of the new commit, the "merge commit".  That is the way
that the vast majority of merges function.  However, for Emacs's
"skipped commits" it is sometimes only half-true, at best.

For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3
and all 8ba6a's descendents.  However, its contents -- i.e. its diff --
are not.  At least, not exactly in the diff form as they were created,
because, as you say, they may take on a different form.  I'll add that
in the case of a bugfix commit, that bugfix may be entirely not
applicable to 'main' become the root cause of the bug being fixed has
been eliminated in the meantime.  Then the skipped commit contents would
simply not be in 'main'.

Nevertheless, a naive Git archeologist will assume 5b038491 to be in
8ba6a38b3 or its descendents, but will _not_ find its contents as easily
as he would some other non-skipped commit from some other regular merge.
If the user is lucky, she'll reach hopefully 8ba6a38b3 and read the
commit message which hopefully explains the situation: "you'd think
5b038 would be here, but it's not because reasons".

In summary, the Emacs way of doing this confuses me (and perhaps other
Git users), as I expect a merge commit to integrate fully the
developments of two or more branches.  That is, when I see it in the
DAG, I expect it to contain the contents of the two or more ancestor
branches.  Modulo conflict resolutions, where "conflict" is defined by
Git's inability to merge automatically (using whichever merge driver).
Of course a project may have sophisticated drivers and/or sophisticated
"semantic" definitions of "conflict" so that even Emacs's way of doing
this could in a way conform perfectly to my expectation if I'm
sufficently aware of those definitions.

Anyway, what could be an alternative?  Well, in other projects I work
with, these re-integrations of "release-and-dev-worthy" fixes into the
main development branch take the form of 'git cherry-pick's.  In Emacs,
this would mean cherry-picking only the "unskipped" commits.  The
cherry-picks' commit messages can be specially marked via a `-x` flag.
Arguably -- though, mind you, I'm not necessarily arguing in this
direction, just presenting an idea-- this is a means to:

* reach the same end goal: to have the release-and-dev-worthy fixes
  integrated into the main branch;

* provide more clarity to Git users who may not be familiar with the
  particular sophisticated definition of a conflict or non-default merge
  drivers.

I've seen multiple project work in this cherry-pick fashion, but I've
not done any kind of survery.  I'm unaware of what the linux kernel
does, for example.  Emacs is the only project I know that uses merges
this way, and afaik, they work fine: I've never personally had a problem
with archeology.

Hope this helps,
João