Rebasing vs merging (was: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs)

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: eggert@cs.ucla.edu,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 17 Aug 2020 20:03:58 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Please don't.  It can cause subtle problems in some rare cases.  Or at
>> > least that's how it was in the past.
>> 
>> If so, it's changed.  There's nothing magical much about rebasing:
>
> I didn't say it was magical, I said it can cause subtle problems.  I
> forget the details, but rebasing after merging could bring the same
> commit more than once.  Or something like that.
>
> Why do you feel the need to rebase?  The default merge that pull does
> is as "non-magical" as rebase.

Rebasing keeps your local changes well localized: on top of upstream
commits instead of mixed with the rest of the history. Plus, once you
send your changes upstream, the result is a linear history or a merge
point consisting of your changes on a side and the rest on the other
side, instead of a maze of changes. Plus+, it is far easier to
self-review and correct your local changes before you send them
upstream, so if your hipotetical "double commit" appears (I have never
seen that, but whatever) it would be immediately obvious.

>> Seems pretty safe to me.
>
> Until it isn't.

Many projects (including Git itself) use rebase as a routine. OTOH, for
the reasons mentioned above, I'll say that unwarranted merges are what
cause problems.