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

Max Horn max at quendi.de
Wed Feb 16 17:09:33 CET 2011


Am 16.02.2011 um 16:53 schrieb 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> 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.

Just to clarify: I agree with Robert, too, and IMHO it is not at all in contradiction with what I said earlier (I think based on Robert's and Johannes email, that impression could arise). For you see: Bigger changes should be in a topic branch anyway (as I stated in my original email). That is, if you make bigger changes, do *not* perform them on your local master branch, but rather on a topic branch just for that. Whether you local merge or rebase this topic branch as time proceeds is up to the individual dev.
The topic branch then eventually is merged (and not rebased) into master, and pushed to the main repository.


Cheers,
Max



More information about the Scummvm-devel mailing list