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.
--
Best regards,
Vladimir ...
