Re: Rebasing vs. merging

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Wed, 19 Aug 2020 12:13:08 +0300
> 
> * 2020-08-17 20:43:02+02, Lars Ingebrigtsen wrote:
> 
> > There's "philosophical" issues with rebasing (in that you're
> > pretending that your own changes are newer than the remote ones), but
> > that's not something we care about.
> 
> Another "philosophical" issue with rebasing is that the resulting code
> is not necessarily tested anymore.

Please note that I didn't want to start any "philosophical" arguments
wrt Git, nor have another "merge vs rebase" argument, of which we had
enough in the past, I think.  All I wanted to say was that we have
discussed this in the past, and decided to use a merge-based workflow
(bugfixes are pushed to the stable branch and then merged to master),
and to stop caring about the merge-commits created by Git when there's
a "push race".

At some point we considered to advise "pull --rebase" or its variants,
but a discussion in Dec 2014 revealed that mixing rebasing with
merge-based workflow can be dangerous, especially if one does local
merges from public branches.  If you have time and motivation, please
read the thread starting at

  https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01444.html

If someone wants to discuss this specific issue, feel free.  But let's
not have another "merge vs rebase" dispute.

Thanks.