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

[Raúl Núñez de Arenas Coronado]

Saluton Ben :)

On Tue, 13 May 2008 21:43:13 +1000, Ben Finney dixit:
> Raúl Núñez de Arenas Coronado <raul at dervishd.net> writes:
> > I'm new to the list and relatively new to Bazaar
> 
> Welcome.

Thanks :)

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

Since (as you point below) there is no master copy, this seems
reasonable and that's what I was assuming.

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

But that will work only for the last commit. Otherwise, my only way is
to revert and rebase, right?.

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

I hate that... but it's reasonable and it's what I would expect from a
distributed VS. My problem is that all my development life I've been
using centralized systems, so it's difficult to change the way of
thinking ;)) You're right and I understand why Bazaar act that way.

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

Probably, but I want the commit history unchanged and the commit
messages without typos ;) The commits are right, but the output of "bzr
log" is not. I don't want to change substantially the messages, I just
want to correct typos and the like. When I said "revision history as
unchanged as possible" I was meaning no merges if possible.

As I told, I come from a centralized VS and I have to change my way of
work and think. In the future, I'll try to be much more careful with
commit messages.

Thanks for the answer :)

Raúl "DervishD" Núñez de Arenas Coronado
-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...