Re: Merges from release branch

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 13:29:27 +0100
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> 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.

No, it's always true, AFAIU.

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

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.

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

Welcome to Git: IME, Git without confusion doesn't exist.

We use the merge workflow because it's the easiest and the less
dangerous one.  We know for a long time that it sometimes produces
confusing and/or suboptimal DAG, but we decided long ago that this is
the price we are prepared to pay in order to make routine usage less
error-prone for those users who are not Git experts and basically use
Git commands as a cookbook they don't always understand 100%.

> Anyway, what could be an alternative?

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