[Scummvm-devel] On using git correctly: Rebase vs. merge

Robert Špalek rspalek at gmail.com
Tue Feb 15 23:54:44 CET 2011


On Tue, Feb 15, 2011 at 8:17 AM, Max Horn <max at quendi.de> wrote:

> BUT watch out, there is a big caveat to that: If you do this, things will
> work nicely most of the time. But not always: Sometimes, git is not able to
> perform the rebase on its own. If Filippos' commit had modified the same
> files as Arnaud's, in the same lines, then git would not have known how to
> handle this. so then, the rebase would have failed. If you had only a
> handful of local commits, this is usually not so bad, and you can recover
> from this using the information git prints on the command line (basically,
> you manually fix the conflicts; then "git add" the conflicted files; then
> run "git rebase --continue"). But sometimes it *does* get problematic, and
> then you might need some experience, or need to read up on this (or ask for
> help from folks in #scummvm) to recover.
>
> in my experience, rebase is only good to do when being trivial or almost
trivial.  if a rebase conflict occurs, then it's usually better in the long
term to merge, because merges keep in the history the following two actions
separate:

(1) programming and debugging your feature
(2) solving a merge conflict

these action were always separate and the benefit of having them separate
even in the repository is usually larger than the extra mess introduced by
nonlinearities.

if one performs rebase and continues development without thorough testing,
and the rebase has brought some subtle bug that will be discovered much
later, then there will be no copy of a working version of the commit in the
repository anymore (!), only a screwed one after botched rebase.  however,
if one instead performs merge, then even if he finds a bug later, it is
possible to check out the earlier unmerged version and merge it again, now
properly.  it's even possible to display a diff between the original and
merged version.

essentially this is the workflow when ones uses feature branches, but I'm
advocating this approach even for single commits when the rebase is not
trivial.

-- 
Robert Špalek <rspalek at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110215/4937e05d/attachment.html>


More information about the Scummvm-devel mailing list