Re: Merges from release branch

[João Távora]

David Engster <deng@randomsample.de> writes:

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

Precisely, though I'm reasonably aware of why and how its done.  I've
explained what I find "confusing" or "peculiar" about it in a longer
email to Esli.

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

I think "evil" as an adjective is suitably exaggerated to characterize
merges where some semantic knowledge of the source (vs Git's purely
formal knowledge) of it, was applied to solve a particular definition of
a "conflict".  Those definitions and semantic insights differ from the
Git defaults, which is concerned with line ranges and hunks.  Newcomer
Git archeologists thus don't have good way to know what kind of merge
they're looking at, short of reading commit messages carefully and or
perusing project documentation.  Moreover the non-defualt merge
techniques may be inconsistently applied across commiters or across time
spans.  In short, this Fear-Uncertainty-Doubt is what could be called
"evil" in a sense.

Of course, if everybody has a full understanding of practices, and
definitions and behaves and follows rules, no FUD exists and nothing
"evil" ever takes place.  But that is a big "if".

João

PS: the 'man gitglossary' definition of an "evil merge" is "a merge that
introduces changes that do not appear in any parent."  I do think this
comprises "removing code that appears in some parent", because that
removal is the introduction of a change that was absent before the merge
commit and present after it.  Linus Torvalds definition is more
sophisticated and better, IMO.  According to [1], he says:

  an "evil merge" is something that makes changes that came from neither
  side and aren't actually resolving a conflict.

In this definition, the concept of "conflict" appears.  Depending on how
you massage that concept, nothing is evil and everything is.