[Top][All Lists]

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

Rebasing vs merging (was: master bdda935 2/2: Merge branch 'master' of g

From: Óscar Fuentes
Subject: Rebasing vs merging (was: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs)
Date: Mon, 17 Aug 2020 20:45:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

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.

reply via email to

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