History editing (Was: Will re-basing support be added into Bazaar core?)

[Ian Clatworthy]

Paul Moore wrote:

> So here's a question:
> 
> If I submitted a change to Bazaar, with commits in there such as
> 
> - Fixed typo
> - Fixed another typo
> - No more time today, committing so I can pick it up tomorrow
> - Broke the test suite, but getting somewhere, try to fix it up later

> would that change be accepted (assuming the end result was clean!)? Or
> would the nature of the intermediate commits be an issue?

Yes. We review the *overall* patch diff, not the individual steps used
to get there.

> For reference, the Mercurial project handles this by expecting
> submissions in patch format, which are nicely managed by the Mercurial
> Queues extension, and which effectively "collapse" my personal history
> into a tidied up version for public consumption.

If you choose to collapse history to hide things prior to review, that's
your choice. It's damn easy to do too. Just use diff to create a patch,
create a fresh branch, apply your patch to it, commit and bzr send.

> From the sound of the
> article by Linus mentioned above, the kernel handles this by
> allowing/expecting contributors to use rebase and history editing
> commands before publishing changes.

Again, none of us care if you use rebase or not to create a submission.
All submissions land via PQM merges so we know that the *mainline* of
bzr.dev is always clean w.r.t. passing the test suite.

> I'm not trying to say that any method is better or worse, I'm just
> curious as to what constitutes "good practice" in what is, it seems to
> me, a relatively new process.

There's nothing wrong with wanting to clean history before publishing
a submission. Rebase is just a pretty blunt instrument for doing that.
I pined for rebase for the first few months after moving from cvs/svn
to bzr, because it automated how I would have done things in the old
world. But the new world really doesn't *require* rebase and I've never
needed it in the dozens/hundreds of changes I've made to Bazaar or its
plugins.

FWIW, when I want to clean history, I take my time and do it manually.
By that, I mean:

* acknowledge my branch is an experimental one that is going to be
  thrown away
* create a new branch
* cherrypick bits across, starting with the bits with minimal
  dependencies
* commit each logical piece, running the test suite on selected
  areas each time if I have *any* concerns
* create the submission using bzr send.

Yes, that's slower than letting rebase do everything for me *but*:

* it really doesn't take long
* I get the chance to improve both the ordering of changes and
  commit messages
* I can be reasonably confident that users or tools (like bisect)
  coming along later will comprehend the history far better than
  they would if I leave things to rebase.

Ian C.