[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rebasing vs. merging

From: Eli Zaretskii
Subject: Re: Rebasing vs. merging
Date: Wed, 19 Aug 2020 17:51:02 +0300

> 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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]