Fix a botched log-message

[Wichmann, Mats D]

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stuart McGraw wrote:
>> Stefan Monnier wrote:
>>>>> How can I fix a log-message in some old revision?
>>>>> (like "cvs admin -m<rev>:<msg>")
>>>> You can't.  History is immutable.
>>> 
>>> This is an annoying limitation.  Botched log messages happen.
>>> And since they don't cause mis-compilations, they tend to be
>>> discovered late. [...]
>> 
>> It can be more than annoying.  Imagine if a programmer
>> added a log message that contained, for example, a sexually
>> harassing comment directed at a coworker.
> 
> We refer to scenarios like this as "nuclear launch codes".  Other
> examples of things that absolutely must be removed are trade secrets,
> source code that is illegally copied, and of course, the launch codes
> to a nuclear missile.

Many people think in terms of a concept (which has been common
since the sccs/rcs days) that code and commit messages are
not the same thing.  Changing the former is treated with much
more seriousness than the latter.  Adjusting a mistyped commit
message is not the same as the "NLC" question, although they
*could* be one and the same if the problem was only in a commit
message. Commit messages may have simpler but still important
problems, like having typed the wrong correlating bug number.
So if I were allowed to dream, I'd love a way to fix commit
messages. I've wished for the ability many times myself, not
least in the case of a tailor-converted branch with a config
problem that caused hundreds of revisions to have inaccurate
data in the commit info but no probem in the actual code
(an unknown problem caused us not ever to be able to successfully
redo the import so we're stuck with it).

The problem, a little less concisely than "history is
immutable" is that in a distributed system, there can be 
uncountable branches made before the "going back in history" 
and there's no way to make those changes propagate out. A
company may be able to do this in a very tightly controlled 
environment, mainly through /policy/: the "master" branch
is controlled by a CM guru, and thou must sync to that
frequently, and if not there are consequences, and definitely
don't ever let any outsider have access to the repository, etc.
I doubt even that is really good enough; even with a centralized
repository, do you go back and fix old backup tapes, which are
a sort of "branch" frozen in time...?