Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

Ben Finney writes:

 > Right. "history" includes not just the commit objects (what I've been
 > referring to as "revisions") but also, importantly, the relationships
 > between them as represented by the branch; their ancestry.

You're confusing the "tree" object with "commit", I suspect.

A git commit includes a tree (by reference), authorship and timestamp
(as literals), and parentage (by reference).  From the point of view
of history relationships, a commit is little more than a list of one
or more arrows in the DAG.  It is the fundamental representation of
ancestry relationships in git.  There is no other[1].

If you have a commit object, then (transitively) you have links to
*all* of its ancestry, unless one or more of its ancestors has been
deleted or corrupted.

 > By saying "rebase loses history" I understand that to mean "rebase
 > loses information encoded in the history of revisions and their
 > ancestry". As I've understood this discussion, that's simple fact:
 > rebase loses information in history by losing the ancestry of revisions
 > in a branch.

That may be true of bzr, but it's definitely not true of git.

The only way to lose ancestry information in git is to delete commits.
git rebase does no such thing.  It *creates* a new chain of commits.
Then it changes the ref to point at the head of the new chain.

Here's a Pythonic allegory:

def update(x):
    return x + 10

# original rebase
class OldRef(object):
    def __init__(self,chain):
        self.branch = chain
    def rebase(self,filter):
        self.branch = [filter(x) for x in self.branch]

a = OldRef([1, 2, 3])
a.rebase(update)

# modern rebase
class NewRef(object):
    def __init__(self,chain):
        self.reflog = []
        self.branch = chain
    def rebase(self,filter):
        self.reflog.insert(0,self.branch)
        self.branch = [filter(x) for x in self.branch]
    def prune(self):
        self.reflog = self.reflog[:5]

b = NewRef([1, 2, 3])
b.rebase(update)

Honestly, what is being "destroyed" or "altered" by .rebase(), either
version, here?

Footnotes: 
[1]  Actually, in turns out that it's convenient to have *partial*
representation of ancestry in the reflog, but it is not sufficient:
some reflog entries do not indicate an ancestry relationship---eg, a
rebase---and some commits---ie, merges---will not have all of their
parentage reflected in the reflog.