Fixing rebase rather than avoiding it

Stefan Monnier monnier at iro.umontreal.ca
Fri Mar 5 22:03:58 GMT 2010


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

Well, you get a new branch that doesn't explain its relationship with
the old branch.  That's the part of the history (i.e. one arc in the
DAG) that's actually really lost.  The rest of the history still exists
but (some part of it) will become GC'able, which means that this missing
arc will lead to futher loss indeed.


        Stefan



More information about the bazaar mailing list