Changing a commit message

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raúl Núñez de Arenas Coronado wrote:
| Saluton Erik :)
|
| On Wed, 14 May 2008 00:08:12 +0200, Erik Bågfors dixit:
|> There has been thoughts about history "annotation". Where you could
|> add a comment to a specific revision. IMHO this would be the perfect
|> way to solve this. The commit message is history that can't be
|> changed, but you can add/remove/modify comments at any time.
|
| OK, an annotation would not be history, but that doesn't solve the
| distribution of such annotations unless they are local. And then you
| have to be careful about which branch are you working on (different
| branches may have different anotations).
|
| Not a bad idea, though.
|
| Raúl "DervishD" Núñez de Arenas Coronado

So the basic idea is that you have 2 DAGs. One is the branch history, the other
is the annotated history. When you modify an old commit, you update the
annotated history with a new node. The annotation graph would probably be
repository wide, but there are various arguments there.

Then when you "fetch" between branches, you check both DAGs for missing revisions.

This also handles stuff like "tags" in a fairly clean manner. (Including the
ability to rollback to an old value for a tag, or the ability to mark a tag as
"deleted" and have that propagated.)

The downside is that it is another DAG to maintain, and another possible source
of conflicts. eg. What happens when we both "fix" a commit message, but we
disagree about the exact text. Now we need a way to communicate to the user that
there is a conflict in the change to the revision message from XXX.

And, as always, the user that gets the conflict need not have made the changes.
Say I make a change, you make a change. Someone branches from me, but ends up
merging your code. Suddenly they get a conflict in a commit revision that they
have *no idea* what it should say. And they have to resolve it in some way. And
then I merge from them, but disagree with the resolution....


Anyway, the technical solution is actually pretty simple. The downside is how
much it makes the UI convoluted, and requires users to do things that they don't
really want to do.

There are other interesting possibilities. Like using it to present a "cleaned
up" view of the history. But does anyone want to be resolving a merge conflict
of 2 cleaned up histories?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgqGZAACgkQJdeBCYSNAAMGqACgjoZg1D6flh4GPx+ai+/htGi3
4dkAnA981ZkIRmhWtY9ov1pRqEZtzJyC
=t/r3
-----END PGP SIGNATURE-----