On Tue, Feb 15, 2011 at 8:17 AM, Max Horn <span dir="ltr"><<a href="mailto:max@quendi.de">max@quendi.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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.<br>

<br></blockquote><div>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:</div>

<div><br></div><div>(1) programming and debugging your feature</div><div>(2) solving a merge conflict</div></div><div><br></div><div>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.</div>

<div><br></div>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.<div>

<br></div><div>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.</div><div><br>-- <br>Robert Špalek <<a href="mailto:rspalek@gmail.com">rspalek@gmail.com</a>><br>


</div>