Will re-basing support be added into Bazaar core ?

[David Timothy Strauss]

----- "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.

> 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.

As another example, let's say we run into patent issues with something like GIF files again. If I create a commit, "Replaced all GIFs with PNGs," and the project rebases against upstream changes that add new GIF files, my message isn't accurate anymore.

There is no commit message that is safe from this problem because you could always create an upstream conflict with any changed code or files and opt for the upstream version during rebase conflict resolution.

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*. Under your proposed system, we would end up binding the most relevant commit information to the tree hash instead of the commit, and rebased commits would basically have blank commit messages with maybe a reference to what was once the relevant commit message.

> 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.

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

-- 
David Strauss
   | david at fourkitchens.com
   | +1 512 577 5827 [mobile]
Four Kitchens
   | http://fourkitchens.com
   | +1 512 454 6659 [office]
   | +1 512 870 8453 [direct]