Changing a commit message

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

Saluton TPJ :)

On Wed, 14 May 2008 09:54:51 +0200, TPJ dixit:
> > (...)
> > Nonetheless, this can be done. The matter here is that in order to
> > allow for modifiable commit messages, a bunch of complication should
> > be put in the code for merges, updates, pulls, pushes, etc. Is it
> > worth the effort? Even I (who would love that kind of change) am
> > doubtful here.
> 
> And I'm not. If it's technically possible (and I'm sure it is), it
> should be done. The rule is simple: don't like it - don't use it, but
> don't limit the way others use Bazaar.

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.

Well, the work involved may be minimum, but this is not the most
important part IMHO. The most important point here is that this feature
may cause database inconsistencies and weird scenarios: you can branch
from two points whose code is otherwise identical, but one of the
possible parent branches has some commit messags and the other has
different commit messages. I, instead of branching right now, would
investigate why they have different commit messages.
 
> I think that the problem is different. In your scenario there are
> problems with propagation of commit messages changes made to old
> revisions, but there aren't any problems with propagation of bug
> fixes. And, IMO, the real problem is that both commit messages bugs
> and source code bugs are *bugs*, but they are treated differently.

They are treated differently because they cannot be fixed in the same
way. In order to fix a bug in the versioned data you create a new
revision and fix it. This is easy to propagate because the core purpose
of a distributed VCS is exactly that, being able to propagate and merge
new revisions in branches. In order to fix a bug in the metadata *of an
old revision* you must break history. 

The problem here is not technical (I'm with you, I'm pretty sure this
can be done), the problem is that you're imposing an extra burden for
users, who may decide to merge something that is not a new revision, but
a change in the metadata of a revision they already have merged (or
branched).

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. IMHO,
it is not worth the pain it would cause to "branchers".

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