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

[Alexander Belchenko]

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?

In this hypothetic(?) situation your patch will be accepted "as is", 
because after merge it will appear as one revision in the mainline with 
good commit message.