Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

Andrew Bennetts writes:

 > Second, it creates a history that you never actually had.

So do the manipulations performed by looms and friends.

 > Depending on what you expect from the history, that may or may not
 > bother you.  If made a commit with a commit message like "Now tests
 > pass on platform X" and then rebase it the commit message will
 > still claim that, but you haven't actually checked that the
 > revision still does pass tests.

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.

and a workflow standard that requires that cherrypicked or rebased
commits get a commit log the references the original commit, and
whether the respective patch applied cleanly or not.

 > Also, it's worth realising that rebasing isn't the only solution to the
 > problem of "I want to present a nice history (in the form of a patch series
 > and/or mainline history) for my work."  For example, although the
 > implementation is certainly still quite rough in parts, the loom plugin
 > quite successfully demonstrates an alternative approach to maintaining a
 > patch series that preserves the original history. 

Actually it's starting to sound to me like looms and filtered views
are "Darcs without patch theory."  That would be pretty cool.