Workflows, rebase, patch theory

[Stephen J. Turnbull]

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

A --- B = mainline          A --- B = mainline --- C = branch
 \                    =>
  C = branch

but what actually happens is

A --- B = mainline          A --- B = mainline --- D = branch
 \                    =>     \
  C = branch                  C

where A, B, C, and D are SHA1s and thus easy to forget.  Most people
just drop C on the floor, but git doesn't (you can verify this with
"gitk mainline branch C", which draws the graph above).  It would be
trivial to make it do this

A --- B = mainline          A --- B = mainline --- C' = branch
 \                    =>     \
  C = branch                  C ~ the-artist-formerly-known-as-branch

where '=' denotes a branch reference and '~' denotes a tag reference.
I always do this by hand if I expect conflicts in the rebase.

 > 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?