Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

David Timothy Strauss writes:
 > ----- "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
 > 
 > >  > Second, it creates a history that you never actually had.
 > > 
 > > So do the manipulations performed by looms and friends.
 > 
 > How is Looms creating history you never had? Unlike StGit, it does
 > not manipulate existing revisions to propagate upstream changes to
 > the patch set.

Unrecorded history is still history.  Ask any feminist.

Also, you misstate how StGit works.  It is not possible to
"manipulate" revisions in git; they are what they are, and *cannot*
change.  What is manipulated are *refs*.

 > > This is a good point, but how often do you see sequences like
 > > 
 > > rev 234: Fix tracker issue #222.
 > > rev 235: Really fix tracker issue #222.
 > > ...
 > > rev 242: Sheesh, I hope I've nailed issue #222 this time!
 > > 
 > > Ie, the problem is not in rebase, but in the writer of the commit
 > > message, and in workflow tool support.  So you can imagine a
 > > test-and-commit tool that runs all the tests and then prepares a
 > > commit log message that starts
 > > 
 > >     Tree <SHA1> passes all tests on platform X.
 > 
 > There is considerable difference between a developer claiming to
 > have fixed an issue in a revision and the objectivity of "test X
 > passes." Nor do I buy that we should play fast and loose with
 > commit messages merely because humans sometimes write inaccurate
 > ones.

Non sequitur.  Please reread what I wrote, and respond to that.

 > The idea of an additional system that binds messages to tree hashes
 > is absurd to me because *that's what commit messages are supposed
 > to be already*.

Your own example belies that.  If commit messages were about the
state, you would phrase it "There are no GIFs, only PNGs, in this
tree" rather than "replaced all GIFs with PNGs".  Commit messages are
usually about the patch, not the tree, in my experience, with the
exception of release banners, references to tests, and (to some
extent) "big merge" tags.

 > Per my GIF example, clean patch application is not a sufficient
 > condition to trust the original commit message on a rebased commit.

That depends on the message.

Personally, I use three-way merges sometimes, and rebase merges
sometimes.  The kind of issue you mention doesn't come up for me
because of the way I use rebase.

On the other hand, suppose you have two long lived branches, and you
merge them.  If the merge is broken, bisect will most likely tell you
that the merge is broken; both branches are fine.  OK, so you exalt
one branch as the mainline, and ask the feature branch to merge it
"regularly".  Guess what?  Bisect will tell you that the merge broke
the feature, and even if you don't get into a finger-pointing war the
feature developers still don't know which (one or more) of her changes
was responsible.  So she has to rebase to get accurate information
about that.

As the bzr developers are fond of saying, There is No One True Way,
and that applies both to the use of rebase and to abstaining from its
use.