<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 02/15/2011 11:54 PM, Robert Špalek wrote:
    <blockquote
      cite="mid:AANLkTi=o22sOJMWNKWJwvCdygLYSvibF-e00bePfEQ4V@mail.gmail.com"
      type="cite">On Tue, Feb 15, 2011 at 8:17 AM, Max Horn <span
        dir="ltr"><<a moz-do-not-send="true"
          href="mailto:max@quendi.de">max@quendi.de</a>></span>
      wrote:<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          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.<br>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    // Johannes<br>
  </body>
</html>