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

[Johannes Schickel]

On 02/15/2011 11:54 PM, Robert Špalek wrote:
> On Tue, Feb 15, 2011 at 8:17 AM, Max Horn <max at quendi.de 
> <mailto: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.

That all seems very sensible to me. I would rather think we should go 
this approach than forcing to rebase for bigger changes, at least it 
seems much more appealing to have a better way of testing on whether the 
initial change or some other change in the main development line caused 
any problems than to have a linear history and no real good way of 
testing that.

// Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110216/77005d38/attachment.html>