# Commit annotations (editable commit messages) 5 messages from 2010-02-12 to 2010-02-13. Participants: Vladimir Panteleev, Avery Pennarun, Mark Lodato, Johan Herland. Thread: https://gitlist.dev/t/22634 ## Vladimir Panteleev, 2010-02-12 22:32 Subject: Commit annotations (editable commit messages) Message-ID: URL: https://gitlist.dev/e/op.u71cw50km02fvl%40cybershadow.mshome.net ``` 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 " 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 mailto:thecybershadow@gmail.com ``` ## Avery Pennarun, 2010-02-12 22:55 Subject: Re: Commit annotations (editable commit messages) Message-ID: <32541b131002121455s46bfe15aie484e9be484259c6@mail.gmail.com> URL: https://gitlist.dev/e/32541b131002121455s46bfe15aie484e9be484259c6%40mail.gmail.com In-Reply-To: ``` 2010/2/12 Vladimir Panteleev : > 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). 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 ``` ## Vladimir Panteleev, 2010-02-12 23:18 Subject: Re: Commit annotations (editable commit messages) Message-ID: URL: https://gitlist.dev/e/op.u71e00v4m02fvl%40cybershadow.mshome.net In-Reply-To: <32541b131002121455s46bfe15aie484e9be484259c6@mail.gmail.com> ``` On Sat, 13 Feb 2010 00:55:46 +0200, Avery Pennarun wrote: > 2010/2/12 Vladimir Panteleev : >> 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). > > 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 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)? -- Best regards, Vladimir mailto:thecybershadow@gmail.com ``` ## Mark Lodato, 2010-02-13 01:01 Subject: Re: Commit annotations (editable commit messages) Message-ID: URL: https://gitlist.dev/e/ca433831002121701u7c4e47ddn2f8bc19c45b2bd03%40mail.gmail.com In-Reply-To: ``` 2010/2/12 Vladimir Panteleev : >> 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 > > Wow, thanks! Looks like I'm behind the times. (Currently stuck with > msysGit/1.6.5) Yes, what you described sounds *exactly* like git-notes :) > The documentation looks pretty scant. Does anyone know how close were my > suggestions to the actual implemented behavior (esp. regarding rebasing)? 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 ``` ## Johan Herland, 2010-02-13 21:46 Subject: Re: Commit annotations (editable commit messages) Message-ID: <201002132246.04558.johan@herland.net> URL: https://gitlist.dev/e/201002132246.04558.johan%40herland.net In-Reply-To: ``` On Saturday 13 February 2010, Mark Lodato wrote: > 2010/2/12 Vladimir Panteleev : > > The documentation looks pretty scant. Does anyone know how close were > > my suggestions to the actual implemented behavior (esp. regarding > > rebasing)? > > 1, 2, 3, and 4 are all implemented, as far as I know. However, I > don't think notes copy during a rebase. 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 -- Johan Herland, www.herland.net ```