Re: Workflow to accumulate individual changes?

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

Karl Fogel writes:

 > There are other ways the system could work.  IIUC, in git the commit
 > message is *not* part of the change's identity,

No, in git the commit message is indeed part of the changes's
identity.  A commit is a strictly defined structure (that happens to
be UTF-8 text with a final, free-form "comment" field), and the whole
thing is hashed to get the SHA1 identifying the commit.

What git has (and Mercurial, though implemented very differently) is
tag *objects*.  The tag object can contain arbitrary content (eg, a
signature), but here it could be used in some conventional way (eg, by
naming it "<sha1>-log-<log-rev-no>" to record an edited message for
commit <sha1>.

 > But I don't know if git has a way of propagating those edits to
 > other clones;

git commit --amend creates a new commit, propagated in the usual way
for commits.  git tag -a creates an annotated tag, propagated in the
usual way for tags.

 > In any case, IMHO it is a minor feature regression that we can no longer
 > tweak log messages after the fact, but it's not a huge problem.

The problem is that in a DVCS there is no reasonable way to propagate
those changes, and it becomes an issue of what the "official" message
for that commit is.  Eg, suppose you tweak.  Now different "official"
messages are going to propagate -- some people already have that
commit, and will *not* refetch it because the identity (SHA1) hasn't
changed.  Others will update or clone, and get it.

In other words, in git the way to notify other clients that you've
changed the commit message is to change the commit ID.  This is true
of all of the DVCSes I've used.