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

[Paul Moore]

2009/4/20 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:
> in that case, looms are indeed better. I think having the 'true' history
> does not matter, prefer a 'pretty' history and enjoy the rebase
> simplicity. So it looks like we use tools which suit us better, which is
> kind of the point.
[...]
> I am sorry, I don't know the exact expression - I was referring to what
> was previously mentioned about rebasing breaking the ordering, and thus
> having tested a branch with 3 commits A->B->C did not imply any
> successful run once this is rebased on another branch. This seems to
> matter a lot to bzr's philosophy and bzr's developers.

This raises a question I've not yet found a good answer for. Nearly
all of my DVCS use so far has been for private code, so issues around
publishing changesets and repositories are unfamiliar to me.

It seems to me that the "history is immutable" philosophy is fine up
to a point, but only for published history. For private work, I want
to make things tidy before I publish it, and I think that's a
reasonable thing to do. In this, I suspect that my view is similar to
David's (above) and it also seems similar to what Linus Torvalds says
in http://article.gmane.org/gmane.comp.video.dri.devel/34744.

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? If my
changes would not be accepted as is, how would the Bazaar developers
recommend that I modify my work to make it acceptable?

Note - I don't accept that *any* changes to my personal workflow (the
chaotic mess that resulted in those commits :-)) should be needed.
After all, one of the main points about a DVCS is that it allows me to
use local lightweight branches to develop changes as I wish.

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

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.

Paul.