Re: Workflow to accumulate individual changes?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Karl Fogel writes:
 > Juanma Barranquero <lekktu@gmail.com> writes:

 > >Well, I can agree with that if you can agree that perhaps rebase
 > >*could be* the best fix after all... ;-)
 > 
 > I've never used 'bzr rebase', and have no competency to evaluate the
 > arguments either way here, but... wouldn't something would smell fishy
 > if rebase were part of our regular workflow?  That somehow seems wrong.

No, it's a matter of style.  Let me summarize:

1.  Everybody agrees that rebasing a branch which is not 100% private
    is problematic.

2.  Some people like rebasing private branches before pushing them,
    basically because it makes the history more linear.  (git people
    generally do.)  Making the history more linear often makes
    bisection more effective, because (except for the initial graft)
    the patches tend to be smaller and localize the defect better.

3.  Some people dislike rebasing private branches, because it makes
    the history more linear.  (bzr people generally do.)  There are
    two reasons typically given:

    a.  Work done concurrently is "misrepresented" as being
        sequential.  I suspect these people generally have an
        intuition of b, but don't express it that way.

    b.  It's easy to think that all commits have properly tested
        because all commits on each (original) branch and the tip have
        been tested, but that is false.  In fact, all commits between
        the graft point and the tip need to be retested.  Of course,
        "need" is assuming a "test every commit" discipline.

    There's a reason that is not typically given, too.

    c.  In some DVCSes, rebase destroys history.  It is in general not
        possible to recover the original branch from a rebase given
        only the "after" DAG.  In bzr a rebase makes recovering the
        original branch a task for someone familiar with the
        internals.  (It may even be impossible in some cases, I don't
        know enough about the internals to say.)

If it's not obvious, let me state that I am biased toward the
pro-rebase side.  But that's a matter of taste.