Changing a commit message (was: Changing a commit message, upgrading from -subtree formats)

[Ben Finney]

Raúl Núñez de Arenas Coronado <raul at dervishd.net> writes:

> I'm new to the list and relatively new to Bazaar

Welcome.

> Right now I only have two problems with Bazaar. First one regards
> commit messages. I've noticed a couple of commit messages in some of
> my projects containing typos or a horrible redaction, and I would
> like to change them.

Bazaar has no way of knowing who else has a branch that depends on
this one (this is seen as a feature). So, Bazaar generally frowns on
changing history, including any aspect of an existing revision.

> Using a non-distributed VS like Subversion, I achieved that using
> "svn-admin" and changing the log message in the repository, but
> since Bazaar is distributed, there is no "master" copy to be
> modified.

Any branch may be treated as "the master branch"; but that's up to the
people who use Bazaar, and isn't a property of that branch.

> I know that, but let's assume that the branch I have at place X is
> the master branch and everybody branches, merges and checkouts from
> it.

There's no way for Bazaar to distinguish this from a branch that does
not have these properties. Again, that's a good thing.

> So, how could I change a commit message in that branch?

The one "change history" command in Bazaar (to my knowledge) is the
'uncommit' command. You can use that, then re-commit the same changes
with a different message.

> Would everyone get the new message if branching, updateing, pulling
> or merging from my branch or do they have to specify the exact
> revision whose message got changed?

Bazaar depends on revisions uniquely identified across all branches,
and that a revision, once it exists somewhere in any repository, will
not change. So, no, those branches that have copies of a specific
revision will intentionally avoid re-fetching revisions they already
have stored in their local repository.

> So far the only way of changing the message I can think about is
> branching the offending revision, uncommiting it, fixing, commiting
> and merging, but that is a bit of a mess because I want the revision
> history as unchanged as possible (so I would prefer to avoid
> merges).

This is at odds with wanting to change history in the first place.
Surely if wanting the commit history to be unchanged, one would also
want the commit messages to be unchanged.