[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Workflow to accumulate individual changes?
From: |
Stephen J. Turnbull |
Subject: |
Re: Workflow to accumulate individual changes? |
Date: |
Fri, 01 Jan 2010 22:49:00 +0900 |
Karl Fogel writes:
> Juanma Barranquero <address@hidden> 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.
- Re: Workflow to accumulate individual changes?, (continued)
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2010/01/02
- Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
- Re: Workflow to accumulate individual changes?, Eli Zaretskii, 2010/01/02
- Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/02
- Re: Workflow to accumulate individual changes?, Eli Zaretskii, 2010/01/02
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2010/01/02
Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
Re: Workflow to accumulate individual changes?,
Stephen J. Turnbull <=
Re: Workflow to accumulate individual changes?, Stephen J. Turnbull, 2010/01/01
Re: Workflow to accumulate individual changes?, Alfred M. Szmidt, 2010/01/01
Re: Workflow to accumulate individual changes?, Alfred M. Szmidt, 2010/01/01