Re: Workflow to accumulate individual changes?

[Karl Fogel]

Andreas Schwab <address@hidden> writes:
>Eli Zaretskii <address@hidden> writes:
>
>> A commit message is not history
>
>It is an integral part of the commit.

This is an old debate in the DVCS world.  The issue is that changes are
distributed and there is no "master copy" of a given change; instead,
there are many copies of the same change, and you can tell they're the
same because they all have the same unique id (and same contents).

In CVS, the master copy is always in the repository and there is exactly
one repository.  So if you want to read log messages, you do 'cvs log'
and it contacts the repository (or, in Emacs's case, 'cvs update' gets
updates to the ChangeLog files, but that also contacts the repository).

In Bzr, the savannah trunk branch is sort of the equivalent CVS's "the
repository"... but the changes in that branch are replicated among
hundreds or thousands of developers' local branches.  If you tweak a
commit message on the savannah branch, bzr has no mechanism for
conveying that tweak to the other branches, because the commit message
is considered part of the change, just like the diff.  Tweak the commit
message and you've tweaked the change -- it's no longer the same change.

There are other ways the system could work.  IIUC, in git the commit
message is *not* part of the change's identity, it's just attached to
the change, so you can edit the message later.  But I don't know if git
has a way of propagating those edits to other clones; nor do I know what
git would do if two different clones tweak a commit message for the
"same" change in two different ways and then one of them has to receive
the other's edits.  Is there conflict resolution on "out-of-band" data,
and if so, how would it work?

Perhaps the difficulty of that question is why bzr doesn't support this.

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.

-Karl