Changing a commit message

[TPJ]

> (Raul Nunez wrote:)
> The problem is that if you use it and I branch or merge from you,
> you're forcing ME to use it, since I would have to merge that change
> too. And yes, I'm somewhat forced to merge changes in the code, of
> course, but probably I WANT to merge code changes. What if I don't
> want to merge changes in the comments because I think it is not
> worth the effort? Then our branches would be diverged even if the
> code is identical in both branches.

An interesting point of view. Let's look at this situation:
a) using this "commit message change" feature (cmc for short) might
force *you* to merge something you don't want to merge.
b) not using this cmc feature might force *me* to not fix a bug in a
commit message.

I think that the solution might be simple: each project has some
leader - a person responsible for this project, for its main branch,
for its repository. I think that the leader is the person who should
make the decision whether commit messages can be changed or not.

Let's assume it's possible to create a repository and/or a branch
which won't allow any changes of commit messages.

You don't want/like it, you don't use it - and it's your project
policy. I know this policy and I know that if I branch something from
your trunk, and then I won't be able to fix any commit messages.

If I don't like it, I don't have to participate in your project! ;)

Now, let's consider another scenario. I am a leader of my project, and
my project's policy is to allow commit messages changes. If you don't
like such a policy, you don't have to participate in my project - thus
you don't have to cope with this cmc feature. You have the same
choice, as I have!


In another words: let the project's leader make this decision, not the
software we use (Bazaar).


> (Raul Nunez wrote:)
> Certainly this is a feature I want on centralized VCS's, but after
> this thread I'm no longer sure about wanting it on a distributed
> VCS.

And that's the point! Remember, that Bazaar allows both decentralized
and *centralized* workflows!

I prefer the latter ones, and hence I'm opting for this feature... :)


Best regards,

         Tomek "TPJ"