Re: log format for vc-bzr

[Stefan Monnier]

>> There is nothing wrong with that, but do that only in your private
>> local branch and don't publish those junk commits.

> That's easy to say, but frequent rebasing is not a desirable option in
> bzr.  If the junk commits bother the community, then you should make
> it an explicit policy that people simply should not make junk commits
> in any branch that might eventually be pushed to the mainline.

FWIW, I've been using two different VCS for the past many years: one for
my own local Emacs branch (was Arch and is now Bzr), and the other (CVS)
for the upstream.  That means I can't just push my changes upstream,
instead I have to copy patches "manually".

A friend recently asked me how I was "pushing" my changes and whether
switching to Bzr was done so that UI could do such "push" more easily,
and after thinking about it, I came to the conclusion that it probably
wouldn't change that much to my workflow: most of my local patches are
developped in a piecemeal fashion with lots of silly commits in
inconsistent states and many of them have been written years ago and
then regularly merged with upstream changes, so the history is
really messy.

Furthermore, this "copy the patch by hand" is usually not as simple as
it seems: very often I end up rewriting the whole change from scratch,
because in retrospect I see that it would be cleaner to do it some
other way.  I.e. the "commit" is an occasion for me to revisit my
change, clean it up, etc...

So I completely agree: such tiny changes are great for your proviate
branch, but you have to clean then up before you install them on
the trunk.  If you end up rebasing too often, it means your change is
old and it deserves taking a second look (e.g. to make sure it was kept
uptodate with other changes), so don't rebase too often: instead just
merge and know that when will come the time to install the change,
you'll have to recreate a clean history by hand.

The good thing about it is that the history you create doesn't have to
reflect the true history: it can be much cleaner, simpler, more linear.
You can create it specifically so that it is easy to understand.
This is in constrast to the real history of that changem which will
often involve trying a few different implementation strategies,


        Stefan