Commit annotations (editable commit messages)

You have to agree, being able to edit commit messages in a controlled (logged/versioned) fashion is pretty useful. Aside mundane corrections such as typos or undocumented changes, it makes it possible to document bugs and other unintended changes in the commit that they were introduced. This is possible in centralized VCSes and is implemented in Subversion (controlled by a server-side hook).

When I presented somewhere the idea of migrating from SVN to Git, I got an  
opinion that the inability to edit commit messages (without rewriting  
history) would be a show-stopper, so I began to wonder how would it be  
possible to implement versioned editable commit messages (or commit  
"annotations") in Git:
1) the repository has a separate, special branch that only contains text  
files named by the SHA-1 of the commit they are describing
2) commit annotations are created/edited by creating/editing the  
respective text files, either manually or using some utilities (e.g. "git  
edit-annotation <SHA-1>" could check out the file from the branch, open up  
an editor and commit it back)
3) setting up "git push/pull" to also push/pull the annotations branch
4) "git log" and related commands would also show the contents of the  
respective text files, if they exist

The first three seem trivial... I'm not sure how to approach 4) though. Would it be possible to hack git to add a commit message output preprocessor hook OSLT?

There's also the problem with rebasing. Aside hacks with copies or symlinks in the annotations branch, what would be the best way to have an annotation follow commits after they're rebased (and have a different SHA-1)? Perhaps tie them to some property unique to the commit (timestamp?)? Depending on how this idea (and git rebase) is implemented, it could also just copy over the then-current version of the annotation into the new commit message when rebasing the commit.

2010/2/12 Vladimir Panteleev <thecybershadow@gmail.com>:

It sounds like you want to read about a new feature called git-notes: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html

Have fun,

Avery

On Sat, 13 Feb 2010 00:55:46 +0200, Avery Pennarun <apenwarr@gmail.com> wrote:

Wow, thanks! Looks like I'm behind the times. (Currently stuck with msysGit/1.6.5)

The documentation looks pretty scant. Does anyone know how close were my suggestions to the actual implemented behavior (esp. regarding rebasing)?

2010/2/12 Vladimir Panteleev <thecybershadow@gmail.com>:

Yes, what you described sounds *exactly* like git-notes :)

1, 2, 3, and 4 are all implemented, as far as I know. However, I don't think notes copy during a rebase. My gut feeling is that you probably shouldn't be rebasing so much that this is an issue. I'm guessing that you should copy the note to the new commit ID after the rebase.

I have also found the documentation lacking. It helped a bit to see the history. It's pretty compact in the logs. Here are two commands to isolate the commits:

git log --reverse fed8a7de3592~..df27f6280545 gitk fed8a7de3592..df27f6280545

-- Mark

On Saturday 13 February 2010, Mark Lodato wrote:

The last patch of the latest iteration of the jh/notes series (posted 5 minutes ago) adds a "git notes copy" command that does just this. Patching rebase/cherry-pick/amend to call "git notes copy" should be fairly straightforward.

...Johan