Re: Merges from release branch

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> I think you are confusing between the ancestry in the DAG sense of the
> word, on the one hand, and the contents of the merged commits, OTOH.

What I'm trying to tell you is that -- by default -- in Git, merging
_means_ composition of contents of the ancestors, modulo trivial
patch-application conflicts.  So there's a clear relation between the
two things: DAG ancestry and code contents.  Git allows you to invent
arbitrary meanings for merging, but deviating from the default is
confusing to... those who expect the default.

> We examined the alternatives when we switched to Git, and decided they
> all are either more complicated, or more dangerous, or both.

Of course, there are cons to everything: integrating back by
cherry-picking involves creating different commits with the same
headline&contents, so that if you have many 'emacs-2x' commits to
integrate back they all appear again in 'main' (but never twice in
'main').  That could be tiresome to some.  Also, with cherry-picks
alone, there's no clear way to tell from the DAG when Glenn decided to
"integrate back" like there is now.  However someone could argue that
those cons are outweighed by the fact that no merge commits exists and
that ancestry at a given point of the DAG now tells any Git user which
code changes are operating at a given point.

As to a specific "danger", I'm intrigued.  Like Drew, would have to see
a particular "dangerous" scenario before I can comment on it.  The
enormous Git threads of 5-6 years ago I remember are too daunting to
re-read.

João