Changing a commit message

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

Saluton Stuart :)

On Tue, 13 May 2008 14:08:33 -0600, Stuart McGraw dixit:
> Raúl Núñez de Arenas Coronado wrote:
> >>> Probably, but I want the commit history unchanged and the commit
> >>> messages without typos ;)
> >> The commit message is part of the revision data.
> > 
> > I know, I shouldn't be changing revision data, and this looks
> > reasonable to me: if you want good commit messages, write them
> > right!
> 
> By the same argument we don't need debugging or refactoring
> tools -- simply write bug-free and correctly designed code
> in the first place.

It's not the same, more on this below.
 
> > Wanting to change the commit messages is weird, and until
> > Subversion I never thought about doing that. The fact that you can
> > change them in Subversion with svn-admin doesn't mean that this is
> > a desirable behaviour in a VS, and clearly it is NOT desirable in
> > distributed VS's.
> 
> I disagree, it is perfectly reasonable desire, and the lack
> of this capability is a defect (IMO) in two DVCS I am interested
> in.

The problem I see here (and I didn't see before) is that in a
non-distributed VCS there's a master copy, so if you modify the log
messages, everybody gets the modified messages. In a distributed VCS
there is no master copy, so let's say I modify a commit message in my
branch and you do the same in yours, with no modification in the data,
so both branches are identical except in metadata (if we consider the
commit messages as metadata). This would introduce a conflict for
something that is not data, complicating merges, updates, etc.

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.

> >>> 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.
> >> A better way to change your way of thinking would be to accept that
> >> the commit messages are part of history, that a VCS is designed to
> >> record history, and abandon the idea of trying to change history.
> 
> There is no value to the vast majority people to preserving
> a history that documents "the" was spelled "th" at commit time.
> There is almost always a negative value to documenting that a
> a committer typed "fixed bug id 1230" instead "fixed bug id
> 1235", especially when (as you point out) one cannot simply
> commit a corrected message like one can with a file.

I see, but such a "bug" (getting the corrected bug number wrong and
putting it in the commit message) would spread very rapidly in a
distributed VCS. In a project with many collaborators, some of them may
branch before the message is fixed, others after that, and people may do
merges between their branches which now would differ not only in the
changes they made, but in the changes YOU made when you fixed the
message. The implications are big, since the only way of having the last
version of all commit messages is doing "bzr update" as frequently as
you can, but you don't want to do an update if you're working in your
own branch isolated. This would make subsequent merges even more
difficult.

Even more complex: I make a project, commit some revisions and you
branch from it. I add more revisions to my branch, you do the same with
your branch. I merge from your branch and add more revisions. Later, a
third person branches from me again. But you notice that one of the
revisions you added to your branch (which I merged) has a bad commit
message. You modify it. But your bad message is in my log, too, from
when I merged, and anyone who branched from me before you fixed the
message would have the bad message too. Updating all non-diverged
branches would be a PITA, but diverged ones would be... almost
impossible.

Even if Bazaar would simulate a data change so the modification to the
commit message propagates correctly, the change is not in the latest
revisions, it has been made on a revision I already have, I already
modified or even I already propagated to people branching from me.

I don't see how this kind of changes (made to old revisions but which
cannot be reflected in the last revision, unlike a revert) can be
propagated unless we track who branched from who and how. That is,
unless we centralize.

> > Again, thanks for your answer. I now see things differently.
> 
> Too bad, I wish more people would recognize it for the problem
> it is an agitate (or better, propose code) that fixes it.

As I told above, I don't see a clean way of doing this. I'm not talking
about code, but about use cases, and I see use cases where having
modifiable commit messages would complicate things. I think it is a
price we have to pay for being distributed, maybe.

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