Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > flexibly supporting various workflows without external scripts and
 > > other muss 'n' fuss, I think it should support rebasing (and in
 > > general history manipulations) well.
 > 
 > Exactly.  Supporting rebasing well means that it should *also* support
 > rebasing without loss of history.

Well, as far as I can remember from an earlier discussion with Robert
Collins, in bzr as in git *locally* you do not lose any history.  ISTR
that up to a repack operation, bzr is append-only.  The revision data
is still there, the metadata is still there.  What you lose is what
git calls a ref: there's no easy way to get a handle to pre-rebase
history once the rebase is done.  However the revid is still valid, so
if you store that externally you can recover the history.

The problem is that branches from this branch, and pushes from this
branch, do not transmit that information.  Which means that early
branches from this one may not be able to communicate with later
branches from this one.

Maintaining some sort of reflog should be trivial, and I suspect that
as long as the data hierarchy (revisions contain pointers to container
data, but no containers or container data themselves; similarly
containers and their content) is respected, that would not impact
storage requirements too heavily.

However, I don't think that's sufficient to support rebase well.  More
like, what is needed are (1) a way for bzr to automatically detect
rebasing, and (2) a design for The Right Thing To Do in such a case.