Re: Workflow to accumulate individual changes?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:
 > > From: Óscar_Fuentes <ofv@wanadoo.es>
 > > Date: Fri, 01 Jan 2010 05:03:57 +0100
 > > 
 > > Richard Stallman <rms@gnu.org> writes:
 > > 
 > > > Is there no way to fix an error in a commit message?
 > > 
 > > You can undo a commit with `bzr uncommit'.
 > 
 > But the issue is not to undo the commit, only fix the text of the
 > commit message.  Something similar to "cvs admin -mREV:MESSAGE".

There's no reason practical or otherwise not to do uncommit, then
commit again, as long as you're on a private branch.  git and darcs
provide "git commit --amend" and "darcs amend-commit" which do exactly
what you want, except that they change the identity of the commit (see
below).  Eg as a shell function

bzr-amend-last-commit () {
    COMMIT_LOG=$1
    bzr uncommit
    bzr commit -m "$COMMIT_LOG"
}

There are also filter-branch capabilities in both git and bzr (quite
expensive in bzr, though) that would allow you to amend an old commit
log on a private branch.

If I really needed to fix a message in a published git branch I would
use a heavyweight tag named "README-something".  I don't think there's
anything similar in bzr, though.

 > Typos in commit messages still can happen, even with bzr ;-)

This has been endlessly discussed on at least the Darcs and Bazaar
lists.

The gist is that the commit log is part of the historical record, and
is checksummed, along with the rest of the history data (eg date and
author information).  This checksum becomes part of the revision
identifier, and thus if you change any of the data, including the
commit log, you've changed the identity of the revision.  As described
elsewhere, that revision identifier is used in various places; it's
not an implemention-internal datum.

I don't think there's any theoretical problem with attaching the log
message externally (at least, external to the checksummed content) as
a comment, somehow.  However, from personal experience I can say that
while I still make the same number of typos in log messages as when I
was using CVS, I make far fewer errors of the form of omitting
important information because I commit much more frequently and my log
messages are both shorter (per message) and more detailed.  So I
suspect you'd get resistence to such a suggestion, both on principle
("The log message is part of history") and practically ("there's no
real benefit, it would take work to do, and it slightly weakens our
internal consistency guarantee").