Workflows, rebase, patch theory

[Andrew Bennetts]

Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
> 
>  > However, rewriting recorded data
> 
> "There you go again."
> 
> In git-rebase, no data are *re*written, except for *one* "pointer".  A
> new branch is *created*, and the old name is moved to its tip (that's
> where the "pointer" gets overwritten.  People always draw this

I didn't say “overwritten”.  I said “rewritten”.  Writing something again does
not imply that the original is destroyed, any more than saying I'm rewriting an
essay to produce a second draft implies that I've necessarily destroyed the
first draft.  Or more topically, when I rewrite code, I generally still have the
previous version in revision control somewhere.

[...snipped description of what rebase actually does.  Don't worry, I really do
get it, even if you with disagree with my choice of terminology...]

>  > Looms are an example of an alternative approach to this problem
>  > that doesn't require synthesising a new, conflicting history.
> 
> Looms are indeed an interesting approach, although I haven't actually
> used one in anger so I don't know how I'll feel about the way history
> is presented by bzr in a loom.  However, I don't think of rebase as
> synthesizing a *conflicting* history, I think of it as creating a
> *coexisting* history.  That's a personal preference, of course, not a
> matter of accuracy.  Ie, the question will be do I prefer bzr-loom's
> presentation of "topic branches" or git-rebase's?

Yeah, that's still an open question.  I suspect the answer today is that you'd
prefer git-rebase, just because bzr-loom's UI still has a few rough edges to be
polished.  As bzr-loom matures, I expect we'll see more threads like this one
popping up...

-Andrew.