Workflows, rebase, patch theory

[Stephen J. Turnbull]

Ben Finney writes:

 > My understanding is this: The state of the tree to which a revision
 > was applied is a fact of history that gets "thrown away" by rebase.
 > 
 > Is that wrong?

Absolutely!  Both the tree object and the commit that refers to it are
in the repository, accessible via their SHA1s and any other tags or
branches that refer to the commit object.  States *and history* are
preserved.  Only the reference via the rebased branch name is not.

If there are no references[1] left, then objects including tree states
and commit history *can* be garbage-collected.  But that only happens
if the user insists.

 > > This is a genuine, important problem, but if you identify it as
 > > "throwing away history" then you probably are eliminating a large
 > > fraction of the possible ways to solve it.
 > 
 > I hope the above makes it clear why we're considering it so.

"Why" has always been clear.  However, Linus (and many others) clearly
consider rebase to be a useful tool in *some* circumstances, and it
has been added to bzr as plugin.  People will use it, so it's better
to identify the problems with it correctly so they can use it
judiciously.


Footnotes: 
[1]  In git the SHA1 name of an object is not considered a reference.