Will re-basing support be added into Bazaar core ?

[Robert Collins]

On Mon, 2009-04-20 at 16:42 +0900, Stephen J. Turnbull wrote:
> David Timothy Strauss writes:
> 
>  > [Rebasing] can be "evil" from the perspective that existing branch
>  > history is sacred and should not be altered.
> 
> Altering history is an implementation detail.  Eg, it won't happen in
> git, because it's impossible in git.  The point is that in git history
> is encapsulated in commits, whose truenames cannot change.  "Branches"
> are merely special nicknames for particular commits, which have the
> feature that if a new commit is created with the parent being the tip
> of the active branch, it will advance the pointer to the new commit.
> 
> It is possible to "lose history" in git by first moving the branch ref
> to a non-descendent commit, then allowing the reflog and the commit to
> be garbage-collected, of course.  But if you turn off the garbage
> collector, git will never lose history (short of a bug or hardware
> failure, of course).  And it can't alter history at all.

When users talk about altering history, particularly in the context of
rebase, they are not talking about altering the content of commits in
the $vcs database. Rather they are talking about how the order and
content of commits reachable from a given human name change when a
rebase operation is executed. 

To quote Linus 'rebase turns tested code into untested code'.

Given three tree states, A, B, C, where A is trunk when I start my work,
B is my new commit on A, and C is a commit to trunk (so also on A),
rebasing B on C gives a fourth tree state, B', which is a commit on top
of C.

If any change in C would make B' be a bad commit - and this is only
slightly about textual conflicts, then B' has been created from B
without taking C into consideration.

This is the heart of why rebase is problematic - it has nothing to do
with the machinery of doing rebase, and everything to do with what the
operation *sets out to achieve*.

A similar issue is at the heart of why bzr asks for merges to be
committed rather than just saying 'why this was a merge, enjoy'.

In the checkout discussion, you seemed to say that git will do a merge,
during a push operation where two refs have diverged (that is, the
server has B, local has C, both B and C are children of A). There really
are only two operations to fix this situation: rebase C on B||B on C, or
merge C and B to give D. What does git do, by default, in this
situation?

>  > At this point in my arguments, you're probably thinking, "So, just
>  > don't use rebasing." But I strongly believe that Bazaar core should
>  > provide a safe, coherent set of tools by default.
> 
> Well, it doesn't.  But that has little to do with what operations it
> provides.  It's an issue of design and implementation of the history
> database.  Bazaar's branch-centric (ie, linear) design makes it very
> difficult to safely provide DAG operations other than commit and merge.

Could you expand on this, I don't understand the limitations in play
here. Is it a limit on the number of refs we can have in a repository
(no limit in the code)? Something else? 

>  > For each problem, we should try hard to find one really great
>  > solution rather than build a smattering of related utilities (like
>  > rebase) that can cleverly be combined to solve the problem.
> 
> Rebase is not a utility.  It is the name of the VCS operation that
> could be defined as presenting a particular linearized account of
> partially ordered history.  Eg, it is implicitly done by every log
> operation.  It is simply[1] a choice of a particular total order on
> the portion of a DAG between a fork and a merge.

I appreciate the concept that git is about history presentation, but
there is a distinct difference - a qualitative difference - between 'log
this differently' and 'change the DAG, and the content of commits'.

log is very much _not_ the same thing as rebase, not in git, hg or bzr.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090420/681c91da/attachment.pgp